WCAG 2.0 達成方法集

1. 一般的な達成方法

G1: メインコンテンツエリアへ直接移動するリンクを各ページの先頭に追加する

適用 (対象)

リンク機能を提供するウェブコンテンツ技術すべて

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.1 (ブロックスキップ)
- クイックリファレンス 2.4.1 (ブロックスキップ)
- 達成基準 2.4.1 (ブロックスキップ)を理解する

解説

この達成方法の目的は、ウェブページのメインコンテンツへ直接移動できるようにすることによって、複数のウェブページ上で繰り返されているコンテンツのブロックをスキップできるメカニズムを提供することである。メインコンテンツの開始位置へのリンクが、そのウェブページの最初のインタラクティブなアイテムとなるようにする。そのリンクを実行することにより、その他のコンテンツを通過して、フォーカスをメインコンテンツへ移動させる。この達成方法は、ウェブページに同じくらい重要なコンテンツエリアが複数ある場合よりも、ウェブページのメインコンテンツエリアが一つである際に最も効果的である。

注記: キーボードで操作している利用者 (スイッチの利用者を含む)、キーボードストロークを遅めにしている利用者、画面拡大ソフトウェアの利用者、画面を見ている人と一緒に作業しているスクリーンリーダーの利用者、キーボードだけで操作している利用者、及び音声認識ソフトウェアの利用者にとっては、このリンクは常に表示されていることが望ましい。しかし、達成基準 2.4.1 は、フォーカスを受け取っていないときには表示されていることを要求してはいない。フォーカスを受け取っているときだけ表示されるリンクも達成基準を満たすことが可能である。

事例

事例 1: オンライン新聞

あるオンライン新聞には、次のような情報のセクションが多くある: 例えば、検索機能、企業ロゴ、関連記事、マイナーな記事、問合せ方法、など。ページの真ん中には、トップ記事が掲載されている。利用者がそのページを Tab キーで操作する際、最初のリンクは「トップ記事へスキップ」というリンクである。そのリンクを動作させると、視覚的に認識できるフォーカスがトップ記事へ移動する。その次に Tab キーを押下すると、そのトップ記事にある最初のリンクへ移動する。

訳注: WAIC では G1-1 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: G1-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2: 「メインコンテンツへスキップ」というリンク

ウェブページには、各ページにさまざまなナビゲーション手法が盛り込まれている: 例えば、パンくずリスト、検索、サイトマップ、そして関連情報の一覧など。そのページの最初のリンクは、「メインコンテンツへスキップ」というリンクである。利用者は、そのリンクを動作させると、それらのナビゲーション機能をスキップすることができる。

訳注: WAIC では G1-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: G1-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

参考リソース

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

Skip Navigation Links

検証

手順

リンクがそのウェブページ上で最初のフォーカス可能なコントロールであることを確認する。
リンクのラベルがメインコンテンツへのリンクであることを示していることを確認する。
リンクが、常に画面に可視である、又はキーボードフォーカスを持つときに可視であるかのいずれかであることを確認する。
リンクを動作させると、フォーカスがメインコンテンツに移動することを確認する。
リンクを動作させた後、キーボードフォーカスがメインコンテンツへ移動することを確認する。

期待される結果

上記のチェックの結果全てが真である。

この達成方法が「十分な達成方法」の一つである場合、この手順や期待される結果を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。

G4: コンテンツを一時停止させて、一時停止させたところから再開できるようにする

適用 (対象)

動きやスクロールのあるコンテンツのあるウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、コンテンツの動きやスクロールの一時停止方法を提供することである。利用者が、動きを一時停止させる、注意をそらすものを減らす、又は読む時間を作る必要があるのであれば、そうすることができ、さらに必要に応じて動きやスクロールを再開できるようにする。このメカニズムは、WCAG に準拠したインタラクティブなコントロール又はキーボードショートカットを介して提供できる。もしキーボードショートカットを用いるのであれば、ウェブページで利用者に説明する。

事例

ウェブページの上部に、スクロールするニュースのバナーが表示されている。これを読むのにより多くの時間が必要な利用者は、Esc キーを押すと、スクロールを一時停止できる。そして、Esc キーをもう一度押すと、スクロールが再開する。
ウェブページには、Flash アニメーションにリンクする「靴紐の結び方」というリンクがある。リンクの直前のテキストは、スペースキーを押すとアニメーションを一時停止し、もう一度押すと再開することを利用者に知らせる。

検証

手順

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

ウェブページで、又はユーザエージェントによって提供されているメカニズムを用いて、コンテンツの動き又はスクロールを一時停止させる。
その動き又はスクロールが停止し、勝手に再開しないことを確認する。
提供されているメカニズムを用いて、コンテンツの動きを再開する。
動き又はスクロールが、停止したところから再開することを確認する。

期待される結果

2. 及び 4. の結果が真である。

G5: 利用者が制限時間なしで操作を完了できるようにする

適用 (対象)

この達成方法は、機能性のための制限時間付きインタラクションを求めない操作方法をサポートする、あらゆる技術又は手法に適用される。

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.3 (タイミング非依存)
- クイックリファレンス 2.2.3 (タイミング非依存)
- 達成基準 2.2.3 (タイミング非依存)を理解する

解説

この達成方法の目的は、利用者が操作の完了に必要な時間を、利用者に提供することである。この達成方法は、制限時間付きインタラクションを必要としない操作方法を提供することにも関連する。利用者には、操作に必要なだけの時間が認められる。

事例

ある授業のインタラクティブな試験には、一つのページに全ての問題を載せている。利用者には全ての問題を解き終えるのに必要なだけの時間が与えられている。
あるインタラクティブなゲームで、利用者は制限時間内に移動を完了しなければならない代わりに、自分のターン上で好きなだけたくさんの時間がかけられる。
あるオンラインオークションで、入札者は時間をずらして複数回の競争入札を提出するのではなく、一つの値段だけを提出できる。入札は丸一日開かれており、簡単な入札フォームへの入力を完了するのに十分な時間が、誰にでも与えられる。ひとたび入札が閉じられたら、もっともよい値段が勝利する。

参考リソース

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

Top Ten Web Design Mistakes of 2005

検証

手順

制限時間付きのインタラクションがあるかどうかを判断する (クライアントサイド及び／又はサーバーサイド)。

期待される結果

1. の結果が偽である。

G8: 拡張音声解説が付いたムービーを提供する

適用 (対象)

音声及び映像をサポートする、あらゆるウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、映像コンテンツに対して拡張した音声解説のある二つめのバージョンを提供することである。一般的な音声解説の作成に伴う困難の一つとして、非常に短い発話の合間に、たくさんの情報をナレーションで提供しなければならない状況が時々生じることが挙げられる。発話の止まる合間が適切な音声解説を提供するのに十分でない場合は、拡張した音声解説を提供するために音声と映像を一時停止して、重要な情報を伝えられるようにする。

拡張音声解説のあるムービーという二つめのバージョンを提供することによって、このコンテンツを全盲の利用者にとってアクセシブルにすることができる。全盲の利用者は、発話を聞くだけでなく、登場人物の発話からだけでは理解できない文脈や映像が伝えるその他の情報も聞く必要があり、そのためには主音声の発話が止まる合間だけでは時間が足りないことがあるからである。

また、付加的な音声解説を必要としない人にとっては視聴の妨げとなるため、多くの場合、この機能のオン及びオフを操作する方法が提供されている。また、別の方法として、付加的な音声解説を含んだバージョンと含まないバージョンの両方を提供することもできる。

事例

事例 1

炎に包まれた建物から脱出する家族の様子を描いたオンライン映像の代替版で、子どもたちがどこにいるかを確認しあう夫婦の会話が絶え間なく続けられている。その間にも夫婦の後ろで壁が崩壊するが、これにより建物のこの部分からの脱出が不可能になるため、これは物語にとって重要な情報である。映像は、ここでトラックを停止して (同じフレームが繰り返される)、ナレーターが壁の崩壊についての詳細を説明した後、再び再生が始まる。

事例 2

研修ビデオで、ほぼ全編にわたって絶え間なくナレーションが続いている。この映像を見るのが困難な利用者のために代替版が用意されており、その代替版では、映像の再生を停止して、重要な情報の音声解説を提供している。

参考リソース

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

検証

手順

拡張音声解説のあるバージョンのムービーを開く。
必要なナレーションを入れる十分な間隔が主音声の発話と発話の間にないとき、拡張音声解説を再生するために映像が一時停止することを確認する。
必要な情報が音声解説で提供されていることを確認する。
代替版が別のウェブページにある場合、利用者がその別バージョンへアクセスを可能にするリンクの有効性を確認する。

期待される結果

2.、3. 及び 4. の結果が真である。

G9: ライブの同期したメディアに対してキャプションを作成する

適用 (対象)

視聴覚の情報を提示する全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 1.2.4 (キャプション (ライブ) )
- クイックリファレンス 1.2.4 (キャプション (ライブ) )
- 達成基準 1.2.4 (キャプション (ライブ) )を理解する
注記: この達成方法は、達成基準 1.2.4 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.2.4 を理解するを参照すること。

解説

この達成方法の目的は、音声を聞くことができない利用者がリアルタイムに同期したメディア放送にアクセスできるようにすることである。間違いを訂正するか、二度聞き又は単語が正確に再現されていることを確認するため誰かに意見を聞く時間がほとんどないので、正確なリアルタイムのキャプションを作成することはより困難である。情報があまりに速く流れている時は、簡略化又は言い換えもさらに困難である。

リアルタイムのタイピングテキスト入力技術には、速記及び高速タイピング技術を使用するものが存在する。復唱による音声テキスト変換 (人が音声を聞き、彼らの音声を覚えこませたコンピューターへ慎重に復唱する) は、今日の電話リレーサービスで使用されており、将来的にはキャプション作成に使用されるかもしれない。ゆくゆくは補正機能を持つ音声テキスト変換が可能になるだろう。

事例

事例 1

テレビスタジオでは、オンラインのイブニングニュースのキャプションを作成するために、リアルタイムのキャプションサービスを利用している。

事例 2

利用者がオンラインセミナーを、Communication Access Real-time Translation (CART) の使用を通したキャプションが提供された上で、モバイルデバイスで視聴している。そして、そのキャプションが、キャプションをデバイス上で目視することが必要なリアルタイムの参加者に利点を提供している。

参考リソース

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

検証

手順

キャプションがリアルタイムに配信されることを保証するため、手順及びポリシーが所定の位置にあることを確認する。

期待される結果

1．の結果が真である。

G10: 名前 (name) 及び役割 (role) を取得し、利用者が設定可能なプロパティを直接設定可能にし、変化を通知するためにユーザエージェントが動作する、プラットフォームのアクセシビリティ API 機能をサポートするウェブコンテンツ技術を用いて、コンポーネントを作成する

適用 (対象)

アクセシビリティ API と連動するようにプログラムされた標準のコンポーネントがあるプログラミング技術

これは、次の達成基準に関連する達成方法である:

達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- クイックリファレンス 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- 達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )を理解する

解説

この達成方法の目的は、支援技術がウェブコンテンツを理解し、代替のユーザインタフェースを介して、利用者に等価の情報を伝えられるようにすることである。

コンテンツのなかには、マークアップ言語ではなく、プログラミング言語又はツールを用いて制作されているものがある。これらのウェブコンテンツ技術には、多くの場合、あらかじめプログラムされたインターフェースコンポーネントがあって、アクセシビリティ API とのインタフェースとなる。コンテンツ制作者がこれらのコンポーネントを使ってプロパティ (名前 (name) など) を埋めると、その結果として生成されるコンテンツのユーザインタフェースコンポーネントは、支援技術にとってアクセシブルなものとなる。

しかし、コンテンツ制作者が新しいユーザインタフェースコンポーネントを作成したいと考え、標準のコンポーネントを使うことができない場合は、自分でアクセシビリティ機能を確実に追加し、アクセシビリティ API と互換性があるように実装する必要がある。

そういったカスタムコンポーネントでは、完成後、アクセシビリティサポーテッドの検証を行うべきである。

事例

あるウェブページでは、アプレットを作成するために Java が使われている。コンテンツ制作者のグループは、まったく新しいタイプのインターフェースコンポーネントを作成したいと考えているため、既存の Java オブジェクトを使うことができない。Java の swing クラスはさまざまなアクセシビリティ API に接続するための規定がすでにあるため、コンテンツ制作者は、コンポーネントを作成するために Java の swing クラスを使用している。Java の swing クラスを使用することで、名前 (name) 及び役割 (role) を公開する、支援技術によって設定される、並びに支援技術に全ての更新に通知を出すインタフェースコンポーネントを作成できる。
C++ プログラミング言語で書かれたオリジナルの Active X コントロールが、ウェブページで使われている。このコントロールは、受け入れコマンドについての情報を公開するために、Microsoft Active Accessibility (MSAA) API を明示的にサポートするように書かれている。その後、このコントロールは、MSAA をサポートするシステム上のユーザエージェントを動作させている支援技術と直接情報のやりとりをする。

H91: HTML のフォームコントロール及びリンクを使用する

検証

手順

アクセシブルなユーザエージェントを用いてコンテンツをレンダリングする。
各ユーザインタフェースコンポーネントを検証するために、ユーザエージェントのアクセシビリティ API 用に設計されたアクセシビリティツールを使用する。
各ユーザインタフェースコンポーネントに対する名前 (name) 及び役割 (role) が、ツールによって検出されることを確認する。
コンポーネントの値を変更する。
アクセシビリティツールにその変更が通知されることを確認する。
コンポーネントが支援技術で動作することを確認する。

期待される結果

各ユーザインタフェースコンポーネントに対して、3、5 及び 6 の結果が真である。

G11: 5 秒未満で点滅するコンテンツを制作する

適用 (対象)

点滅するコンテンツをサポートしているウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.2 (一時停止、停止、非表示)
- クイックリファレンス 2.2.2 (一時停止、停止、非表示)
- 達成基準 2.2.2 (一時停止、停止、非表示)を理解する

解説

この達成方法の目的は、コンテンツが点滅することによって注意がそがれるのを最小限にし、利用者がページ上の他のコンテンツに意識を集中できるようにすることである。

点滅するコンテンツは、様々なウェブコンテンツ技術を用いて制作することができる。その多くには、点滅するコンテンツを連続的に繰り返し再生させたり、点滅するコンテンツを表示させる長さを指定したりするオプションがある。点滅するコンテンツの長さを 5 秒より短い時間に限定することで、点滅が引き起こす混乱を最小限にすることができる。これはあるタイプの学習障害がある人や弱視の利用者の役に立つ。

事例

アニメーション画像がセール中の商品を強調するために使用されている。購入対象の商品リスト内で、赤いタグの画像の後に「セール中」というフレーズが続き、割引価格で提供されている商品を示すために使用される。赤いタグの画像はページの読み込み時に点滅し、5秒以内に停止する。

検証

手順

点滅するアイテムをすべて探す。
点滅するそれぞれのアイテムについて、点滅の始まりから終わりまでの間隔が 5 秒より短いかどうかを確認する。

期待される結果

2.の結果が真である。

G13: コンテキストの変化を引き起こすフォームコントロールへの変更が行われる前に、何が起こるのかを説明する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、フォームコントロールへの変更がコンテキストの変化をもたらすときに何が起こるかについての情報を利用者に提供することである。一般的にフォームコントロールの値を変更することはコンテキストの変化をもたらさないため、コンテンツ制作者が事前に利用者に振る舞いに気づくような説明を提供することが重要である。可能であれば、その変化についての説明とフォームのコントロール自身をプログラム的に関連づけておく方がよい。

次に示すのは、さまざまな状況における説明の提供方法の例である。

設定変更によってコンテキストの変化が生じるインタフェース要素よりも音声読み上げ順序が前になるように、ウェブページ上で説明を提供する。
設定変更がコンテキストの変化を引き起こすユーザインタフェース要素に到達するために、利用者が特定のステップを完了させなければならないようなステップが複数あるプロセスに対して、コンテキストの変化が起きるステップの前にプロセスの一部として説明を提供する。
設定変更によってコンテキストの変化を引き起こすユーザインタフェース要素のあるウェブアプリケーションを利用する前に、利用者のトレーニングが必要とされるイントラネットの場合、そのトレーニングの一部として説明が提供される。

事例

トップページで、ドイツ語、フランス語とスペイン語という選択肢がラジオボタンで示されている。ボタンの前には、利用者に対して、選択肢を選ぶことで言語が変更されるという説明が示されている。
オンライン調査で 50 問の質問が一つずつ表示される。調査の初めに、利用者が各質問に対して回答を選ぶと次の質問に進むことができるという説明が表示されている。

参考リソース

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

G80: コンテキストの変化を開始する送信ボタンを提供する

検証

手順

フォームコントロールの設定変更により、コンテキストの変化が生じるコンテンツの場所を見つける。
コントロール操作の前に、コントロールが変更されたときに何が起こるのかの説明が利用可能であるかを確認する。

期待される結果

2.の結果が真である。

G14: 色の違いで伝えている情報をテキストでも入手可能にする

適用 (対象)

すべての色やテキストをサポートするウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.1 (色の使用)
- クイックリファレンス 1.4.1 (色の使用)
- 達成基準 1.4.1 (色の使用)を理解する

解説

この達成方法の目的は、フォームの必須項目のように、情報を伝えるために色の違いを用いるとき、色の違いによって伝えている情報をテキストも用いて明示することである。

事例

事例 1: 色でコード化されたスケジュール

技術会議のセッションスケジュールが三つのトラックで構成されている。このとき、トラック 1 のセッションが青い背景色で、トラック 2 のセッションが黄色い背景で、トラック 3 のセッションが緑色の背景で示されているならば、トラック 1 はＴ1、トラック 2 はＴ2、トラック 3 はＴ3 のように、各セッション名に続きテキストでも示されている。

事例 2: 色のアイコンでコード化されたスケジュール

技術会議のセッションスケジュールが三つのトラックで構成されている。各セッションのタイトルの隣りに色を用いたアイコンがあり、青はトラック 1、黄はトラック 2、緑はトラック 3 であることを示している。それぞれのアイコンには、トラック 1、トラック 2、トラック 3 と適切なテキストによる代替が提供されている。

事例 3: 必須項目のあるフォーム

フォームにいくつかの必須項目がある。必須項目のラベルは赤で示されている。それに加えて、各ラベルの後ろに＊ (アスタリスク) がある。フォーム入力の説明文では、入力例に続いて、「赤字で＊ (アスタリスク) の付いた項目は必須項目です。」と示されている。

注記: アスタリスクは、スクリーンリーダー (やその読上げモード) によっては読上げられないことがあり、またデフォルトの文字サイズよりも小さいサイズで表示されるため、弱視の利用者にとっては見づらいかもしれない。コンテンツ制作者としては、アスタリスクが用いられていることをテキストで示すとともに、表示されるアスタリスクの文字サイズを大きくすることが重要である。

事例 4: 緑色の送信ボタンのあるフォーム

オンラインのローン申し込みにおいて、緑色のボタンでプロセスを進め、赤色のボタンでプロセスをキャンセルできると説明がある。このとき、フォームは、緑色のボタンにはテキストで「Go」と書かれていて、「緑色の[Go]ボタンを押して結果を提出し、次のステップに進んでください」と指示がある。

参考リソース

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

検証

手順

情報を伝えるのに色の違いが用いられている各項目に対して:

伝えられている情報がテキストでも利用可能であり、そのテキストが条件付きコンテンツでないことを確認する。

期待される結果

1.の結果が真である。

G15: コンテンツが一般閃光閾値及び赤色閃光閾値を越えていないことを確認するためにツールを使用する

適用 (対象)

あらゆるウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 2.3.1 (3 回の閃光、又は閾値以下)
- クイックリファレンス 2.3.1 (3 回の閃光、又は閾値以下)
- 達成基準 2.3.1 (3 回の閃光、又は閾値以下)を理解する

解説

一般閃光閾値と赤色閃光閾値を違反しているかどうかを検証する目的は、光感受性による発作のある利用者が、発作を起こしそうなコンテンツに遭遇することなくウェブサイトを閲覧できるようにすることである。警告を示すという方法もあるが、見逃すことも考えられるし、また子どもたちは警告があっても読めなかったり、理解できなかったりするかもしれない。この達成方法を用いることによって、コンテンツのチェックができるので、一般閃光や赤色閃光の閾値を違反している場合は、サイト上で用いないことにするか、あるいは閾値に反しないように修正する。

注記 1: 特定の単純な閃光であれば用いることができる検証がある。例えば:

コンテンツが 1 秒間に 3 回あるいはそれよりも少ない回数の閃光を放つものであれば、G19: どの 1 秒間においても、コンテンツに 3 回よりも多く閃光を放つコンポーネントがないことを確認するを用いることができる。
コンテンツが画面上で一度に一箇所でだけ閃光を放ち、その面積が十分に小さいならば、達成方法 G176: 閃光を放つ領域を十分に小さくするを用いることができる。

注記 2: その他の場合は、すべての要因を把握し、連続する時間単位で映像に適用するツールが必要である。

事例

雷のアニメーションにおいて、稲光が 6 回閃光を放つ。閃光はとても速く、大きく、閃光の解析ツールで検証したところ、一般閃光閾値に違反している。アニメーションは、稲妻閃光が 2 回続いた後に短い休止が入るように編集されている。変更後のアニメーションは、一般閃光閾値に違反していない。

参考リソース

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

検証

手順

コンテンツが一般閃光閾値及び／又は赤色閃光閾値に違反していないかどうかを確認する。

ツールを使って、一般閃光閾値も赤色閃光閾値も超えていないことを確認する。

期待される結果

1. の結果が真である。

G17: テキスト (及び文字画像) とその背景の間に、少なくとも 7:1 のコントラスト比を確保する

適用 (対象)

視覚的なアウトプットを生成するウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.6 (コントラスト (高度) )
- クイックリファレンス 1.4.6 (コントラスト (高度) )
- 達成基準 1.4.6 (コントラスト (高度) )を理解する

解説

この達成方法の目的は、利用者が背景の上にあるテキストを読めるようにすることである。この達成方法は、4.5:1 のコントラストをもたせる達成方法よりも基準が上回るもので、さらに高いレベルのコントラストを提供することでロービジョンの利用者が読みやすくする。

もし背景が無地の色 (又は真っ黒、真白) の場合、個々のテキストの文字が背景とのコントラスト比を 7:1 で保持することによってテキストのコントラスト比を維持することができる。

背景または文字が相対輝度において変化する (またはパターン化されている) 場合、たとえ背景全体とのコントラスト比を 7:1 で保持していなくとも、文字の周囲の背景、又は陰影によって、文字と背景のコントラスト比を維持することができる。

背景の相対輝度がページの中で変化する場合は、文字の相対輝度も変化させることによってコントラスト比が維持されることもある。

もし通常では背景画像又は背景色の相対輝度が十分でない場合は、他の方法として、テキストの周りに後光を付けて必要なコントラスト比をもたせる方法もある。

事例

企業ロゴに合った明るい色の文字を使うことができるように、背景には黒が使用されている。
テキストが大学のキャンパスの写真の上に書かれている。写真には、さまざまな色や明暗があるので、テキストの下のエリアを白っぽくぼやけさせることで、淡い色調になり一番暗い所でも写真の上に書かれている黒いテキストとの 7:1 のコントラスト比を維持するのに十分に明るくなっている。

参考リソース

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

検証

手順

以下の公式を用いて、各文字 (すべて同一ではない限り) の相対輝度を測る:
- 色の相対輝度 L = 0.2126 * R + 0.7152 * G + 0.0722 * B と定義されている。この場合の R, G 及び B は:
  - R_sRGB <= 0.03928 の場合: R = R_sRGB/12.92、それ以外の場合: R = ((R_sRGB+0.055)/1.055) ^ 2.4
  - G_sRGB <= 0.03928 の場合: G = G_sRGB/12.92、それ以外の場合: G = ((G_sRGB+0.055)/1.055) ^ 2.4
  - B_sRGB <= 0.03928 の場合: B = B_sRGB/12.92、それ以外の場合: B = ((B_sRGB+0.055)/1.055) ^ 2.4
  注記: また、R_sRGB, G_sRGB, 及び B_sRGB は以下のように定義される:
  - R_sRGB = R_8bit/255
  - G_sRGB = G_8bit/255
  - B_sRGB = B_8bit/255
  注記: "^"記号は指数演算子である。
注記: エイリアス文字の場合は、文字の端から 2 ピクセルの部分の相対輝度の値を使用する。
同じ公式を用いて、文字のすぐ隣の背景のピクセルの相対輝度を測る。
次の公式を用いて、コントラスト比を算出する。
- (L1 + 0.05) / (L2 + 0.05) ここで、
  - L1 は前景又は背景色の明るい方の相対輝度である。及び、
  - L2 は前景又は背景色の暗い方の相対輝度である。
コントラスト比が 7:1 以上であることを確認する。

期待される結果

4. の結果が真である。

G18: テキスト (及び文字画像) とその背景の間に、少なくとも 4.5:1 のコントラスト比を確保する

適用 (対象)

あらゆるウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、利用者が背景の上にあるテキストを読めるようにすることである。達成基準 1.4.3 に関しては、この達成方法は 18pt (太字ではない: 日本語の場合は 22pt) 未満と 14pt (太字: 日本語の場合は 18pt) 未満のテキストのための最小コントラスト比を説明している。さらに、達成基準 1.4.6 においては、この達成方法は少なくとも 18pt (太字ではない: 日本語の場合は 22pt) 又は少なくとも 14pt (太字: 日本語の場合は 18pt) のテキストに対して 7:1 のコントラスト比を要求している。

注記: この達成基準を評価する際、フォントサイズのポイント数は、ユーザエージェントから得られるか、あるいはユーザエージェントが行うフォントメトリクスによって計算されるであろう。ポイントのサイズは、CSS の pt を定義する CSS3 Values に基づく。ポイントと CSS のピクセルとの比率は 1pt = 1.333px であるため、14pt と 18pt はそれぞれおよそ 18.5px と 24px に等しい。

もし背景が無地の色 (または真っ黒、真白) の場合、各テキストの文字が背景とのコントラスト比を 4.5:1 で保持することによってテキストの相対輝度を維持することができる。

背景または文字が相対輝度において変化する (またはパターン化されている) 場合、たとえ背景全体とのコントラスト比を 4.5:1 で保持していなくとも、文字の周囲の背景又は陰影によって、文字と背景のコントラスト比を維持することができる。

例えば、文字の上部が下部よりも明るい場合、文字と背景のコントラスト比を文字の周り全体で維持することが難しい。その場合、文字と背景のコントラスト比 4.5:1 以上を保持するため、背景を暗くするか、細い黒枠線 (少なくとも 1 ピクセル) を追加する。

コントラスト比は、背景の相対輝度がページをまたがって変化する時に、文字の相対輝度も変化させることによって維持されることもある。

例えば、ページの一端が非常に明るく、反対側の非常に暗い一端に向かってフェードする場合、ページ全体を通してコントラストの基準を満たす色は存在しない。対応する方法のひとつは、文字のその時の背景に対してコントラスト比を満たすように、文字の明るさを変化させることだろう。

もし、背景画像または背景色が標準的に相対輝度で十分に違いがない場合は、他の方法として必要なコントラスト比を提供したテキストの周りに後光を提供する方法もある。

事例

黒い背景を選ぶことによって、企業ロゴに合った明るい色の文字を使うことができる。
テキストが大学のキャンパスの写真の上に書かれている。幅広いさまざまな色や色合いが写真に現れているので、テキストの下のエリアが霧のような白にすることで、写真はとてもかすみ、一番暗い所は写真の上に書かれている黒いテキストとの 4.5:1 のコントラスト比を維持するのに十分な明るさである。
参考リソースのコントラストについてのサンプル ("Color Contrst Samples") も見ること。

参考リソース

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

訳注: 「Colour Contrast Analyser」は 2018 年現在、Firefox Add-ons から入手できない状態にある。

(今のところ、なし。)

検証

手順

以下の公式を用いて、各文字 (すべて同一ではない限り) の相対輝度を測る:
- 色の相対輝度 L = 0.2126 * R + 0.7152 * G + 0.0722 * B と定義されている。この場合の R, G 及び B は:
  - R_sRGB <= 0.03928 の場合: R = R_sRGB/12.92、それ以外の場合: R = ((R_sRGB+0.055)/1.055) ^ 2.4
  - G_sRGB <= 0.03928 の場合: G = G_sRGB/12.92、それ以外の場合: G = ((G_sRGB+0.055)/1.055) ^ 2.4
  - B_sRGB <= 0.03928 の場合: B = B_sRGB/12.92、それ以外の場合: B = ((B_sRGB+0.055)/1.055) ^ 2.4
  注記: また、R_sRGB, G_sRGB, 及び B_sRGB は以下のように定義される:
  - R_sRGB = R_8bit/255
  - G_sRGB = G_8bit/255
  - B_sRGB = B_8bit/255
  注記: "^"記号は指数演算子である。
注記: エイリアス文字の場合は、文字の端から 2 ピクセルの部分の相対輝度の値を使用する。
同じ公式を用いて、文字のすぐ隣の背景のピクセルの相対輝度を測る。
次の公式を用いて、コントラスト比を算出する。
- (L1 + 0.05) / (L2 + 0.05) ここで、
  - L1 は前景又は背景色の明るい方の相対輝度である。及び、
  - L2 は前景又は背景色の暗い方の相対輝度である。
コントラスト比が 4.5:1 以上である。

期待される結果

4. の結果が真である。

G19: どの 1 秒間においても、コンテンツに 3 回よりも多く閃光を放つコンポーネントがないことを確認する

適用 (対象)

あらゆるウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、明るく、その面積が大きいと発作を起こすといわれている速度で閃光を放つことを防ぐことである。面積を拡大して見ている利用者もいるので、この達成方法ではコンテンツのサイズの大きさに関係なく、1 秒間に 3 回より少ない閃光しか用いてはいけないとしている。

注記 1: この達成方法は、レベル A の達成基準よりも厳格だが、検証はより容易であり、レベル A の達成基準を満たすために使用することができる。なぜなら、レベル A の達成基準の全ての失敗例の閾値は、1 秒以内に 3.5 回以上の閃光があるからである。ほとんどのコンテンツには閃光を放つものはなく、点滅があるコンテンツでも稀な場合を除いてこれほど速く点滅しない。したがって、達成基準で規定されているより複雑な検証を実行しなくても済むようにするためには、この達成方法にあるようにコンテンツが 1 秒間に 1、2 回、又は最大でも 3 回までしか閃光を放つだけであることを確認する。

注記 2: 3.5 回の閃光について: もし、明暗が 7 回変化した場合、3.5 回の閃光となり、これは許容される 3 回の閃光 (6 回変化) よりも多い。

3.5 回の閃光又は 7 回の遷移の事例:

始まりが暗い色－明るい色－暗い色－明るい色－暗い色－明るい色－暗い色－明るい色、又は
始まりが明るい色－暗い色－明るい色－暗い色－明るい色－暗い色－明るい色－暗い色

事例

コンテンツに閃光を放つものがある。コンテンツは、続けて 2 回又は 3 回しか光らないように設計されている。

参考リソース

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

Trace Center Photosensitive Epilepsy Analysis Tool (PEAT)

G15: コンテンツが一般閃光閾値及び赤色閃光閾値を越えていないことを確認するためにツールを使用する

検証

手順

どの 1 秒間においても 3 回よりも多い閃光がないことを確認する。
3 回の閃光がある場合、1 秒間の最後の明／暗の状態が開始時と同じであることを確認する。

期待される結果

1. と 2. の両方の結果が真である。

G21: 利用者がコンテンツ内に閉じ込められないことを確認する

適用 (対象)

インタラクティブな操作をサポートするウェブコンテンツ技術すべて

これは、次の達成基準に関連する達成方法である:

達成基準 2.1.2 (キーボードトラップなし)
- クイックリファレンス 2.1.2 (キーボードトラップなし)
- 達成基準 2.1.2 (キーボードトラップなし)を理解する

解説

この達成方法の目的は、マウス又はポインティングデバイスを使わなければ抜け出すことのできないコンテンツのサブセットに、キーボード利用者が閉じ込められてしまわないようにすることである。よくある事例としては、プラグインによって描画されるコンテンツが挙げられる。プラグインはユーザエージェントであり、ユーザエージェントの親ウィンドウの中にコンテンツを表示したり、プラグインがフォーカスを持っている間に起きる利用者の動作全てに反応したりする。もしプラグインが親ウィンドウへフォーカスを戻すキーボードのメカニズムを提供しない場合、キーボードを使用しなければならない利用者は、プラグインのコンテンツの中に閉じ込められてしまうことがある。

この問題は、コンテンツのサブセットから抜け出す方法を提供する以下のメカニズムのうちの一つを使うことによって回避することができる。

コンテンツ内でフォーカスを前進させるためのキーボード機能 (一般的には Tab キー) によって最後のナビゲーション位置に到達した後、コンテンツのサブセットから抜け出せるようにする。
コンテンツのサブセットからフォーカスを出すキーボード機能を提供する。サブセット内でアクセシブルな方法によってその機能を必ず明記する。
コンテンツのサブセットで用いられているウェブコンテンツ技術が自然に「親コンテンツに戻る」ためのキーボードコマンドを提供している場合、利用者がそのプラグインに入る前に、そのコマンドを明記して利用者がどのように再びプラグインの外に出られるかを分かるようにする。

コンテンツ制作者が、利用者がキーボードでサブコンテンツに入れてもデフォルトでのキーボード操作ではそのサブコンテンツから出ることができないウェブコンテンツ技術を使っている (すなわち、ウェブコンテンツ技術又はそのユーザエージェントの機能ではない) 場合、この達成方法を実装するためにはウェブコンテンツ制作者はそのような機能をコンテンツ内に構築するか、又はそのウェブコンテンツ技術を使わないか、どちらかにする。

訳注: WAIC では G21 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: G21 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例

いったん利用者がタブ移動でアプレットの中に入ると、それ以降のタブ移動はアプレットによって処理され、その利用者がタブ移動で外に出られないようになっている。しかしながら、そのアプレットは、アプレット内で連続したタブ移動を終えた時、キーボードフォーカスが親ウィンドウに戻るように作られている。
アクセシビリティサポーテッドではないコンテンツを含んでいるページには、キーボードによってアクセシビリティサポーテッドなコンテンツにフォーカスを戻す方法についての説明がある。その説明は、アクセシビリティサポーテッドではないコンテンツより前に書かれている。
アクセシビリティサポーテッドではないコンテンツから入手可能なヘルプ情報は、キーボード操作によってアクセシビリティサポーテッドなコンテンツへフォーカスを戻す方法を説明しており、そのヘルプ情報はキーボードによるアクセスが可能である。
ウェブページで入手可能なヘルプ情報は、キーボード操作によってアクセシビリティサポーテッドではないコンテンツからアクセシビリティサポーテッドなコンテンツへフォーカスを戻す方法を説明しており、そのヘルプ情報はキーボードによるアクセスが可能である。

参考リソース

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

(今のところ、なし。)

検証

手順

Tab キーでコンテンツ内を最初から最後まで移動する。
キーボードフォーカスがどのコンテンツにも閉じ込められていない。
キーボードフォーカスがコンテンツに閉じ込められてしまう場合、コンテンツから抜け出す方法を説明したヘルプ情報が利用可能であり、キーボード操作でアクセスできることを確認する。

期待される結果

2.の結果が偽である。
訳注: 「2. 又は 3. のいずれかの結果が真である」となるのが正しいと思われる。

G53: リンクテキストとそれが含まれている文中のテキストとを組み合わせて、リンクの目的を特定する

適用 (対象)

リンクが含まれる全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.4 (リンクの目的 (コンテキスト内) )
- クイックリファレンス 2.4.4 (リンクの目的 (コンテキスト内) )
- 達成基準 2.4.4 (リンクの目的 (コンテキスト内) )を理解する

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

G53 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、リンク及びその文脈からリンクの目的を特定することである。そのリンクを含んでいる文章によって、リンクテキストだけでは不明瞭なリンクに文脈が与えられることになる。その説明によって、利用者がそのリンクと、そのウェブページ内にある他のリンクとを区別できるようになり、そのリンク先へ移動するかどうかを判断しやすくなる。一般的に、リンクテキストとして単に目的地の URI を示すだけでは、リンク先の説明として不十分であることに注意すべきである。

注記: このような説明が利用者にとって最も役立つのは、リンクを理解するのに必要な追加情報が、そのリンクよりも前に書かれている場合である。追加情報がリンクの後に書かれていると、ページを (先頭から最後へと) 順番に読むスクリーンリーダーの利用者には混乱や支障が生じることがある。

訳注: WAIC では G53 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: G53 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例

事例 1

ウェブページに「このページ上で広告を掲載する場合は、ここをクリック。」という文章がある。

リンクテキストの「ここをクリック」は、リンク先を理解するのに十分ではないが、必要な情報は同じ文の中でそのリンクの前にある。

事例 2

「スモールヴィルタイムズのリポートによれば、教育委員会が 8 月 27 日にスタートする 2007 年スクールカレンダーを選んだとのことです。」という文章を含んでいるニュースのサマリーの中で、「リポート」が教育委員会の会議についてのスモールヴィルタイムズの記事へのリンクとなっている。

注記: この事例は、達成基準を満たしてはいるが、このようにリンクの後にそのリンクを理解するために必要な情報を置くと、スクリーンリーダーでドキュメントを読んでいる人にとっては分かりにくいものである。

参考リソース

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

検証

手順

コンテンツの中で、この達成方法を用いているリンクそれぞれに対して:

そのリンクが文の一部であることを確認する。
そのリンクテキストと文を組み合わせると、リンクの目的が説明されていることを確認する。

期待される結果

上記全ての結果が真である。

G54: 映像ストリームに手話通訳を含める

適用 (対象)

同期したメディア情報を提示する全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 1.2.6 (手話 (収録済) )
- クイックリファレンス 1.2.6 (手話 (収録済) )
- 達成基準 1.2.6 (手話 (収録済) )を理解する

解説

この達成方法の目的は、耳の聞こえない又は、テキストを速く読むことができない利用者が同期したメディア情報にアクセスできるようにすることである。

主に手話でコミュニケーションをする利用者にとって、キャプションで提示されている速度ではテキストを読んで理解するのが難しかったり、場合によっては不可能であったりする。後者の人については、音声情報の手話による提示を提供することが重要である。

キャプションと手話とを両立できる一般的な方法は、単純に映像ストリームに手話通訳の映像を含めることである。ただし、この方法には、映像全体を拡大する以外には容易に拡大できない低解像度の映像になってしまうという欠点がある。

注記 1: 映像ストリームが小さすぎる場合は、手話通訳が見にくくなる。手話通訳を含む映像ストリームを制作する場合は、映像ストリームをアクセシビリティサポーテッドなウェブコンテンツ技術でフルスクリーンで再生するメカニズムがあることを確認する。そうでない場合は、映像の中の手話通訳の部分が、映像ストリームがフルスクリーンになった際のサイズまで調節可能にする。

注記 2: 一般的に、手話は単に墨字を符号化したものではないため、コンテンツ制作者は複数種類あるうちのどの手話を用いるかを決めなければならない。通常は主な利用者が使用している手話を用いる。さまざまな利用者を想定する場合は、複数の手話を用いる。複数の手話のための推奨達成方法を参照のこと。

訳注: 注記 2 に記載されている達成方法はまだ文書化されていない。

事例

あるテレビ局が、オンラインニュース映像の角の方、又は傍らで手話通訳を提供している。

参考リソース

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

手話を作成するための指針
- "Sign Language presentation"では、手話通訳者を撮影する際の留意点の概要を知ることができる。元の素材が書き言葉の場合と話し言葉の場合の両方についての議論も含まれている。
- 撮影のテクニックについては chapter 12, “Filming the Signer(s)" で考察されている。
- オリジナルの同期したメディアコンテンツに関連して手話通訳を表示させる方法についての有益な情報は Chapter 13, "Editing"で提供されている。
  注記: これらの実装方法はウェブベースのプレゼンテーションにも適用される必要がある。

検証

手順

耳が聞こえて、使用されている手話に精通した人に映像を見せる。
手話通訳が画面上に表示されているかどうかを確認する。
会話及び重要な音が、画面上の手話通訳によって伝達されていることを確認する。

期待される結果

2.及び 3.の結果が真である。

G55: 定義にリンクする

適用 (対象)

リンク機能を含む全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、同じウェブページ又は異なるウェブページの中で定義を提供し、項目とその定義の間にリンクを指定することで、単語、句、又は略語の定義を入手できるようにすることである。

リンクは、単語、句、又は略語の定義へのアクセスを提供するための強力な選択肢である。利用者は、迅速かつ容易に定義を見つけるのにリンクを使用し、それから、ユーザエージェントの戻るボタンによってコンテンツの元の場所に戻る。

事例

事例 1

スポーツ障害に関する記事中の専門用語と略語は、医学辞典の定義にリンクされている。

事例 2

教科書には各章で紹介された新しい単語の用語集がある。これらの単語は初出時に、用語集の定義にリンクが貼られている。

事例 3

略語の一般的な用語集が提供されている。略語が出現するすべての箇所には、用語集の中の適切な定義に直接リンクが貼られている。

事例 4

専門用語 という用語は WCAG 2.0 用語集の定義にリンクされている。

事例 5

「モジュロ」という単語は、数学に関するウェブコンテンツで使用される専門用語である。モジュロの定義はウェブページの中に含まれている。モジュロという単語の各出現時に、その定義にリンクが貼られている。

事例 6

日本語の慣用句は定義にリンクされている。この例は、ページの中で慣用句の定義へ案内するリンクを使用している。

コード例:

<p>....<a href="#definition">さじを投げる</a>....</p>

<h3>脚注:</h3>

<dl>
<dt id="definition" name="definition">さじを投げる</dt>
<dd>どうすることもできなくなり、あきらめること。</dd>
</dl>

参考リソース

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

検証

手順

定義される各単語、句、又は略語について:

少なくともそのアイテムが最初の箇所がリンクであることを確認する。
各リンクがそのアイテムの定義にナビゲートすることを確認する。

期待される結果

1.及び 2.の結果が真である。

G56: 非発話音が発話音声コンテンツより少なくとも 20 デシベル低くなるように、音声ファイルを編集する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.7 (小さな背景音、又は背景音なし)
- クイックリファレンス 1.4.7 (小さな背景音、又は背景音なし)
- 達成基準 1.4.7 (小さな背景音、又は背景音なし)を理解する

解説

この達成方法の目的は、聴覚に問題を持つ利用者が主音声を理解しづらくならないように、コンテンツ制作者が音声に背景音を入れられるようにすることである。前景にある主音声を背景音より 20 デジベル大きくすることで、その主音声は背景音よりも 4 倍大きいことになる。デシベル (dB) に関する情報は、About Decibels を参照のこと。

事例

事例 1: 暴動の様子を伝えるアナウンサー

アナウンサーが暴動の様子を伝えている。暴動場面の音量をアナウンサーの音量よりも 20 デシベル小さく調整してから、その場面とアナウンサーとを編集で重ねている。

事例 2: ナレーターの音声と背景音楽との十分な音声コントラスト

この事例では、ナレーターの音声と背景音楽があり、主音声は背景音楽よりもちょうど 20 デシベル大きい。主音声 (前景) は -17.52 デシベル (二乗平均平方根)、音楽 (背景) は -37.52 デシベルで録音しているため、前景は背景よりも 20 デシベル大きいことになる。

音声サンプル

音声サンプル: 前景音声が背景音楽よりも 20 デシベル大きい (mp3 形式)

音声サンプル (十分なコントラスト) のトランスクリプト:

"Usually the foreground refers to a voice that is speaking and should be understood. My speaking voice right now is 20 decibels above the background which is the music. This is an example of how it should be done.."

訳注: 音声が英語なので、和訳していない。

音声サンプルを視覚的に示したもの

音声サンプルを、音声エディタ上のファイルのスナップショットという形で、以下に視覚的に示してある。前景音声と背景音楽を含んだセクションは強調表示にしてある。背景音楽のみのセクションに比べて、波形がはるかに大きい。

スクリーンショット: 音声エディタを用いて、十分なコントラストのある音声を視覚的に示したもの

失敗例 3: ナレーターの音声と背景音楽との不十分な音声コントラスト

失敗例の音声サンプル

この事例では、ナレーターの音声と背景音楽があり、主音声は背景音楽よりも 20 デシベル以上は大きくない。主音声 (前景) は -18 デシベル、音楽 (背景) は -16 デシベルで録音しているため、前景は背景よりも 2 デシベルしか大きくない。

音声サンプル: 前景音声と背景音楽の差が 20 デシベル未満である (mp3 形式)

音声サンプル (不十分なコントラスト) のトランスクリプト:

"This is an example of a voice that is not loud enough against the background. The voice which is the foreground is only about 2 decibels above the background. Therefore is difficult to understand for a person who is hard of hearing. It is hard to discern one word from the next. This is an example of what not to do."

訳注: 音声が英語なので、和訳していない。

失敗例の音声サンプルを視覚的に示したもの

強調表示にしたセクションは、前景音声と背景音楽を含んだ部分である。背景音楽しかないセクションと波形がほぼ同じ大きさであり、前景音声に比べて背景音楽が大きすぎるということである。

スクリーンショット: 音声エディタを用いて、コントラストが十分ではない音声を視覚的に示したもの

参考リソース

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

About Decibels by Gregg Vanderheiden
Audio creation / contrast tutorial

検証

手順

前景音声が流れている間で、背景コンテンツの大きな値の位置を見つける。
dB(A) SPL で音量を計測する。
dB(A) SPL で前景音声の音量を計測する。
値を引き算する。
差が 20 デシベル以上であることを確認する。

期待される結果

5. の結果が真である。

G57: コンテンツを意味のある順序で並べる

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.2 (意味のある順序)
- クイックリファレンス 1.3.2 (意味のある順序)
- 達成基準 1.3.2 (意味のある順序)を理解する

解説

この達成方法の目的は、支援技術に提示されるコンテンツの順序によって、利用者がコンテンツを理解可能にすることを保証することである。技術の中には、たとえコンテンツが元のソースファイルでエンコードされている順序とは異なるとしても、視覚的にコンテンツを意味のある順序でレンダリングすることを可能にするものがある。

例えば、HTML で異なる表記方向を持つ言語を混在させる場合、双方向アルゴリズムは視覚的レンダリングの誤った位置に句読点を置くことがある。視覚的レンダリングの問題は、コンテンツストリームにおける句読点を移動することで、双方向アルゴリズムが要望通りに配置するように修正できるが、これは間違ったコンテンツ順序を支援技術に公開する。コンテンツは、双方向アルゴリズムを上書きするためのマークアップを使用することによって、正しい順序で視覚的にレンダリングされ、正しい順序で支援技術に公開される。

視覚的に表示したとき、スペース又はタブのような空白文字列は、コンテンツの一部としては見えない。しかし、見た目を整えるためにコンテンツに挿入すると、それによってコンテンツの意味がわかりにくくなることがある。

また、レイアウトテーブルを用いて HTML 文書のコンテンツのブロックの配置を制御することによって、見た目には関連する情報を並べて表示することができるが、コンテンツの流れとしては分断されてしまうこともある。スクリーンリーダーでは、レイアウトテーブルを行から行へと読み上げるので、イラストのキャプションがイラストに続く行に配置された場合、キャプションとそのイラストの画像とを関連付けられないことがある。

事例

事例 1

美術館の展示に関するウェブページに、リンクのリストを含んだナビゲーションバーがある。また、そのページには、展示品のうちのある一つの絵の画像、表題、及び詳しい説明がある。ナビゲーションバーのリンクは意味のある順序となっていて、表題、画像、及び説明のテキストもまた意味のある順序となっている。これらの要素をページに配置するのには、CSS が用いられている。

マークアップ:

コード例:


  <h1>My Museum Page</h1>
  <ul id="nav">
    <li><a href="#">Link 1</a></li>
    ...
    <li><a href="#">Link 10</a></li>
  </ul>
  <div id="description">
    <h2>Mona Lisa</h2>
    <p>
    <img src="img.png" alt="Mona Lisa">
    </p>
    <p>...detailed description of the picture...</p>
  </div>

CSS:

コード例:


  ul#nav {
    float: left;
    width: 9em;
    list-style-type: none;
    margin: 0;
    padding: 0.5em;
    color: #fff;
    background-color: #063;
  }
  ul#nav a {
   display: block;
    width: 100%;
    text-decoration: none;
    color: #fff;
    background-color: #063;
  }
  div#description {
    margin-left: 11em;
  }

参考リソース

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

検証

手順

(例えば、レイアウトスタイルを削除したり、線形化するツールを用いるなど、) ウェブコンテンツ技術の標準的アプローチを使用し、コンテンツを線形化する。
コンテンツの順序が、オリジナルと同じ意味を持つかどうかを確認する。

期待される結果

2. の結果が真である。

G58: 非テキストコンテンツのすぐ隣に、時間依存メディアの代替へのリンクを配置する

適用 (対象)

特定のウェブコンテンツ技術に依存しない。リンクをサポートする全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

解説

この達成方法によって、キャプションと音声解説が照合されたドキュメントへのリンクが提供できる。照合ドキュメントは同じウェブページ内の別の場所、又は別の URI に存在するかもしれない。照合ドキュメントへのリンクは非テキストコンテンツに隣接する。そのリンクは同期したメディアコンテンツの直前、又は直後に配置される。照合ドキュメントが同一のウェブページに異なるコンテンツとして存在する場合、「文章の終わり」と最後に記述し、利用者がいつそれを読むのを終え、元の場所に戻るかを知らせることができる。もし、「戻る」ボタンによって利用者が移動してきた元の場所に戻れない場合は非テキストコンテンツの場所へ戻るリンクが提供される。

事例

事例 1: HTML ドキュメント内の MOV ドキュメント

「Olympic_Sports.htm」という名のページ内のコード

コード例:


  <a name="Olympic_Wrestling"></a>
  <p><a href="http://www.example.com/movies/olympic_wrestling.mov">Olympic Wrestling movie</a>, 
  <a href="http://www.example.com/transcripts/olympic_wrestling_transcript.htm">Olympic 
  Wrestling collated Transcript</a></p>

事例 2: HTML ドキュメント内の .MOV ドキュメントへ戻る

olympic_wrestling_transcript.htm のページ内のコード

コード例:


  <p>Sports announcer 1: This is a great battle tonight between England's "Will Johnson" and 
  "Theodore Derringo" from Argentina</p>
  <p>Scenery: There is a mat set out in the middle of the stadium with 500 people in the 
  stands...</p>
  <p> ...more dialogue...<p>
  <p> ...more scenery...</p>
  <p> ...etc...</p>
  <p>Sports announcer 2: And that is all for tonight, thank you for joining us tonight where 
  Will Johnson is the new Gold Medalist. 
  <a href="../movies/Olympic_Sports.htm#Olympic_Wrestling>Return to Movie page</a> </p>

参考リソース

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

検証

手順

非テキストコンテンツの直前又は直後にリンクが存在するかどうかを確認する。
そのリンクがこの固有の同期したメディアの照合ドキュメントを直接指す有効なリンクであることを確認する。
利用者がその同期したメディアコンテンツの元の場所に戻るためのリンク又は戻る機能が利用可能かどうかを確認する。

期待される結果

１.から 3.の結果全てが真である。

G59: コンテンツ内の順番及び関係に従った順序で、インタラクティブな要素を配置する

適用 (対象)

インタラクティブな要素を含み、インタラクティブな要素のデフォルトのタブ移動順序を定義している、全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.3 (フォーカス順序)
- クイックリファレンス 2.4.3 (フォーカス順序)
- 達成基準 2.4.3 (フォーカス順序)を理解する

解説

この達成方法の目的は、インタラクティブな要素がコンテンツ内でのつながりや関係に即した順序で確実にフォーカスを受けるようにすることである。コンテンツを設計する際、リンク及びフォームコントロールなどのインタラクティブな要素を、デフォルトのタブ順序がコンテンツ内でのつながりや関係に即した順序になるように、コンテンツ内に配置する。それぞれのウェブコンテンツ技術がデフォルトのタブ順序を定義しているため、コンテンツ内でコントロールを配置するメカニズムは、用いるウェブコンテンツ技術に依存することになる。

例えば HTML では、デフォルトのフォーカス順序は、コンテンツのソース内で各要素が登場する順序となる。HTML ソースの順序がウェブページの視覚的な順序に合致していれば、Tab キーを押してコンテンツ内を進む順序は、コンテンツの視覚的なレイアウトと同じになる。ソースの順序が視覚的な順序と合致していないときは、Tab キーを押してコンテンツ内を進む順序が、視覚的に表示されたコンテンツの論理的な順序を反映したものとならなければならない。

事例

フォーム内に、順番に入力すべき二つのテキスト入力フィールドがある。一つめのテキスト入力フィールドはコンテンツ内で 1 番目に置かれ、二つめのテキスト入力フィールドは 2 番目に置かれている。
フォーム内に、二つの情報セクションが隣り合わせに表示されている。片方のセクションには、申込者についての情報が含まれていて、もう片方のセクションには、申込者の配偶者についての情報が含まれている。申込者のセクションにある全てのインタラクティブな要素は、配偶者のセクションにあるどの要素よりも前に、フォーカスを受けるようになっている。そして、各セクション内の要素は、そのセクションを読む順番に従ってフォーカスを受けるようになっている。

参考リソース

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

検証

手順

コンテンツ内のインタラクティブな要素の順序を特定する。
インタラクティブな要素の論理的な順序を特定する。
コンテンツ内のインタラクティブな要素の順序が、その論理的な順序と一致していることを確認する。

期待される結果

3. の結果が真である。

G60: 音声の再生を 3 秒以内に自動的に停止する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.2 (音声の制御)
- クイックリファレンス 1.4.2 (音声の制御)
- 達成基準 1.4.2 (音声の制御)を理解する

解説

この達成方法の目的は、スクリーンリーダーの利用者が、コンテンツで再生される音によって邪魔されてスクリーンリーダーを使えないことがないようにして、コンテンツ制作者がウェブページ上で音を再生できるようにすることである。さらに、音を制御するコントロールを置かなくてもよいようにすることも目的の一つである。スクリーンリーダーの利用者が、(スクリーンリーダーの音が聞こえないために) コントロールを探せないという問題が起こらないようにすることである。

この達成方法はシンプルで、音を 3 秒又はそれより短く再生し、自動的に停止するようにすればよい。

事例

事例 1: ウェブページを開くと、トランペットのファンファーレが鳴り、静かになる。
事例 2: ウェブページを開くと、「品質がビジネスでは一番重要です」という社長の声が聞こえ、静かになる。
事例 3: 「Enter キーを押して始めてください」という始め方の操作説明が流れる。
事例 4: ウェブページを開くと警告音が鳴り、静かになる。

参考リソース

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

検証

手順

ウェブページをロードする。
自動的に再生される全ての音が 3 秒以下で停止することを確認する。

期待される結果

2. の結果が真である。

G61: 毎回同じ相対的順序で繰り返されるコンポーネントを提示する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 3.2.3 (一貫したナビゲーション)
- クイックリファレンス 3.2.3 (一貫したナビゲーション)
- 達成基準 3.2.3 (一貫したナビゲーション)を理解する

解説

この達成方法の目的は、繰り返し現れる一連のコンポーネント中での配置を予測可能にすることによって、コンテンツを使いやすくすることである。この達成方法は複数のウェブページについて、それらのページ中で繰り返される一連のコンポーネントを毎回同じ順序で提示することで、統一されたレイアウト又は提示の記憶を容易にする。それらのコンポーネント間に別のコンポーネントを挿入することはあってもよいが、元のコンポーネント間の相対的順序は変更しない。

この達成方法は、繰り返し出現するナビゲーションのためのコンポーネントについても当てはまる。ウェブページには利用者が他のページにジャンプできるよう、ナビゲーションのためのメニューやそのためのコンポーネントを置くことが多い。この達成方法は、ナビゲーションのためのコンポーネントが繰り返し用いられる度にその中に置かれるリンクやプログラム的参照を一定の順序で提示することにより、コンポーネント間の配置を予測しやすくする。リンク先のウェブページについてそれぞれのサブセクションに移動できるようにしたい場合など、リンクを削除したり、既存のリンクの間に他のリンクを挿入したりしてもよいが、リンク間の相対的位置は変更しない。

事例

あるウェブサイトでは各ページの先頭に、ロゴ、タイトル、検索フォーム、ナビゲーションバーが置かれている。これらは同じ相対的順序で提示される。あるページには検索フォームがないが、その他のコンポーネントは繰り返し現れるどのページにおいてもやはり同じ順序で提示される。
あるウェブサイトでは左側にナビゲーションメニューがあり、サイト内の主要なセクションへのリンクが置かれている。利用者がサイト内の他のセクションへのリンクをたどると、移動先のページでも主要なセクションへのリンクが同じ相対的順序で提示される。ページによっては一部のリンクが省かれたり他のリンクが追加されたりするが、その他のリンクは必ず同じ相対的順序を保っている。たとえば製品とそのトレーニングサービスを提供する企業のウェブサイトでは、ナビゲーションリストには製品とトレーニングサービスが主要なセクションとして提示されている。また製品のページでは個別の製品へのリンクもナビゲーションリスト内に置かれている。利用者が製品のページからトレーニングのページに移動すると、ナビゲーションリストから個別の製品へのリンクが省かれ、個別のトレーニングサービスへのリンクが追加される。

参考リソース

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

検証

手順

ウェブページ一式 (例えば一つのウェブサイト) 中の各ウェブページで繰り返されるコンポーネントをリストアップする。
それぞれのコンポーネントにおいて、そのコンポーネントが現れる各ウェブページで他の繰り返されるコンポーネントに関して同じ相対的順序で現れることを確認する。
それぞれのナビゲーションのためのコンポーネントにおいて、リンク又はやプログラムの参照が常に同じ相対的順序であることを確認する。

期待される結果

2.の結果が真である。
3.の結果が真である。

G62: 用語集を提供する

適用 (対象)

テキストを提供するあらゆるウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、用語集で定義を提供することにより、単語、語句、又は略語の定義を利用できるようにするものである。用語集は、単語、語句、及び略語の定義を伴ったアルファベット順の一覧である。用語集は、単語、語句、及び略語が特殊な分野又は技術領域に関連するコンテンツ内で使用される時に最も適している。用語集は、単語又は語句の発音を提供することも可能である。

用語集はウェブページの最後に記載されているか、又は用語集は、ウェブページ一式の中のコンテンツを検索するメカニズムのうちの一つを使って探し出される。(「達成基準 2.4.5 を理解する」を参照のこと。)

用語集が同じ単語、語彙、又は略語で複数の定義を提供する場合、単に用語集を提供しているだけではこの達成基準を満たすには不十分である。正しい定義を見つけるために異なる達成方法が用いられるべきである。単語、語句、又は略語の用途がウェブページ内で一意でない場合、すなわち、その項目の出現箇所が異なると定義が異なる場合に、これが特に重要である。

事例

事例 1

オンラインのチャットフォーラムの利用者は、コンピュータでのタイピングによる会話のスピードアップのために、いくつかの頭字語や略語を造り出した。例えば、LOL は「高らかに笑う」を意味し、FWIW は「どれほど有用かはわからないけど。」を省略したものである。サイトは、一般的に使用される頭字語及び略語の元の語句を一覧表にした用語集のページを提供している。

事例 2

数学の理論を議論するウェブページには、一般的に使われる数学の専門用語、略語及び頭字語の用語集がある。

事例 3

教科書には、各章で紹介される新しい語彙の用語集がある。

事例 4

オランダ語の言い回しは、「Hij ging met de kippen op stok」(彼は鶏とねぐらに帰った) という語句を使用する。用語集は、この語句が「Hij ging vroeg naar bed」(彼は早く寝た) を意味していることを説明している。

事例 5: 慣用表現の用語集

アメリカの小説「ハックルベリーフィンの冒険」は、1840 年代の南西アメリカで用いられていた多くの固有表現を含んでいる。生徒向けに編集されたオンライン版において、個々の慣用表現は用語集の項目にリンクが張られている。

参考リソース

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

検証

手順

次のいずれかであることを確認する
- 用語集がウェブページに含まれている、又は
- 用語集を見つけるためのメカニズムが利用できる。
定義される個々の単語、語句、又は略語が用語集で定義されていることを確認する。
用語集には個々の項目に対して一つの定義のみが含まれることを確認する。

期待される結果

上記の三つの結果全てが真である。

注記: WCAG で使用される略語の定義は: 「単語、語句、又は名称の短縮形で、短縮されていない元来の名称を当該組織が廃止していないもの、及びその略語が言語の一部になっていないもの。」である。

G63: サイトマップを提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

解説

これは、達成基準 2.4.5 の実装に十分なコンテンツを配置するための一連の達成方法のひとつである。サイトマップは、サイトの異なる区分へのリンクを提供するウェブページである。サイト内でサイトマップを利用できるよう、最低でもサイトマップに記載されている全てのページに、サイトマップへのリンクを設ける。

サイトマップは次のいくつかの目的に役立つ。

サイト全体の概要を提供する。
利用者が、サイトが何を含んでいて、コンテンツがどのように構成されているか、理解するのを助ける。
サイトのいろいろな部分によって異なる、複雑なナビゲーションバーの代替物を提供する。

サイトマップには、様々なタイプのものがある。最も単純で最も一般的な種類のサイトマップは、それぞれの区分又はサブサイトへのリンクを示した概略である。そのような概略は、サイトのいろいろな区分のページ間のリンクのような、サイト内のより複雑な関係は示さない。大きいサイトへのサイトマップの中には、各区分に関する追加の詳細を示すために展開する見出しを使用しているものもある。

サイトマップはサイトのコンテンツと構成について説明する。サイトを更新するときはいつも、サイトマップを更新することが重要である。例えば、下記の一つでも満たしている時、サイトマップは有効ではない:

サイトの全ての区分にリンクしていない、又は
サイトの構成とは異なる構成を提供する、又は
もはや有効ではないリンクを含む

事例

事例 1

ウェブアクセシビリティイニシアティブは、ウェブサイトのいろいろな区分を記載した WAI サイトマップを提供している。サイトマップはウェブサイトのいろいろな区分を示すとともに、それらの区分の下部構造のいくつかを示している。

事例 2

オンラインマガジンのためのサイトマップには、マガジンの全ての区分とそれぞれの区分の小区分が記載されている。また、ヘルプ、お問い合わせ、個人情報保護方針、採用情報、定期購読、及びマガジンの HOME ページ、へのリンクを含んでいる。

参考リソース

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

Usability Glossary: sitemap

検証

手順

サイトにサイトマップがあることを確認する。
サイトマップにあるリンクが、サイトの対応するセクションにつながることを確認する。
サイトマップにある各リンクについて、対象のページにサイトマップへのリンクが含まれていることを確認する。
サイトの各ページについて、サイトマップから始まる一連のリンクを辿ることでページに達することができることを確認する。

期待される結果

上記の全ての結果が真である。

G64: 目次を提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.5 (複数の手段)
- クイックリファレンス 2.4.5 (複数の手段)
- 達成基準 2.4.5 (複数の手段)を理解する

解説

これは、達成基準 2.4.5 の実装に十分なコンテンツを配置するための一連の達成方法の一つである。目次は、同じドキュメントの区分と小区分へのリンクを提供する。ドキュメントにある情報は、通常、階層的に構成され、順々に読まれることを意図している。まさに図書館にある多くの本にそれぞれ目次があるように、ウェブサイトの多くのドキュメントにも目次がある。

目次は次の二つの目的に役立つ:

ドキュメントの内容と構成の概要を利用者に与える。
読者がオンラインドキュメントの特定の区分に直接行けるようにする。

目次はドキュメントの主要な区分だけを含むことが多いが、場合によっては複雑なドキュメントのより詳細な一覧を提供する展開された目次が望ましいかもしれない。

ドキュメントの区分は、同じウェブページに配置する、又は複数のウェブページに分割して配置することができる。目次は、ドキュメントを複数のウェブページに分割するとき、特に役に立つ。

目次とナビゲーションバー又はサイトマップのような他のナビゲーション要素との間には違いがある。目次は同じドキュメント内の区分へのリンクを提供する。それらの区分は、同じウェブページに配置する、又は複数のウェブページにまたがって配置することができる。しかしいずれでも構想を完成させることができる。このことをさらに理解するために、複数の区分のあるハードコピーの本を考えてみよう。各区分は本に属する。図書館には多くの本がある。この例では「図書館」が全体のウェブサイトに相当する。

事例

事例 1

ウェブコンテンツアクセシビリティガイドライン 2.0 には、ドキュメントの区分と小区分へのリンクの階層的なリストである目次がある。目次の階層構造は区分の構成を反映し、目次の各項目は、利用者をその区分に直接連れて行くリンクである。

事例 2

Accessing PDF Documents with Assistive Technology: A Screen Reader User's Guide の目次は 2 ページ目から始まっている。

参考リソース

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

検証

手順

目次、又は目次へのリンクがドキュメントに存在することを確認する。
目次の項目及び順序が、ドキュメントのセクションの名前及び順序と一致することを確認する。
目次の項目が、ドキュメントの各セクションにリンクしていることを確認する。

期待される結果

上記の全ての結果が真である。

G65: パンくずリストを提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.8 (現在位置)
- クイックリファレンス 2.4.8 (現在位置)
- 達成基準 2.4.8 (現在位置)を理解する

解説

パンくずリストは、コンテンツがどのような構造になっていたのか、及びこれまでにたどってきたウェブページへ戻る方法を、利用者が想起する助けとなり、また一連のウェブページの中で現在位置を特定する。パンくずリストには、利用者がそのウェブページに到達するまでに通ってきた場所、又はサイトの編成における現在のウェブページの位置が表示されている。

パンくずリストは、現在のウェブページまでナビゲートする途中にアクセスしたウェブページへのリンクを使って実装される。パンくずリストは、ウェブページ一式の各ウェブページの中で同じ位置に置く。

目に見える区切り文字でパンくずリストの中の項目を切り離すと、利用者の助けになる。区切り文字の例には「>」、「|」、「/」、「::」、及び「→」がある。

事例

事例 1

開発者が、ハイパーリンクを作成する方法を見つけるために、オーサリングツールのメーカーのウェブサイトの中を探している。検索結果を使って、オーサリングツールを使用してハイパーリンクを作成するための詳しい説明があるウェブページへ行く。そのページには、以下のようなリンクでできたパンくずリストがある:

コード例:

Home :: Developer Center :: How To Center

この例では、パンくずリストには現在のウェブページのタイトルである「ハイパーリンクを作成する方法」が含まれていない。その情報はウェブページのタイトルとして入手できる。

事例 2

写真家の作品集のウェブサイトはいろいろなギャラリーに分かれていて、各ギャラリーはさらに分類ごとに分割されている。サイトの中で Gentoo Penguin の写真を含むウェブページに移動する利用者は、ウェブページの冒頭で以下のようなパンくずリストを見る:

コード例:

Home / Galleries / Antarctica / Penguins / Gentoo Penguin

"Gentoo Penguin" を除くすべての項目がリンクとして実装されている。現在位置 (Gentoo Penguin) はパンくずリストに含まれているが、リンクとしては実装されていない。

事例 3

e コマースサイトの情報設計が、一般から特定の製品区分に徐々に分類されている。

You are here: Acme Company → Electronics → Computers → Laptops

パンくずリストが "You are here" で始まり、現在利用者がいるページで終わる。リストに入っている項目は、"You are here" 及び "Laptops" を除いて、クリック又はタップ可能なリンクである。この例は、右向き矢印 (→) を区切り位置として使用している。

この例では、h2 要素、aria-label 属性を指定した nav 要素、非順序のリストがセマンティクスを提供するために使われている。このマークアップは、CSS によるスタイル指定によって水平のパンくずリストとして表示されるだろう。

この例に対する HTML

コード例:

 
          <nav aria-label="Breadcrumbs"> 
            <h2>You are here:</h2> 
            <ul>
              <li><a href="/">Acme Company</a> &#8594;</li> 
              <li><a href="/electronics/">Electronics</a> &#8594;</li>
              <li><a href="/electronics/computers/">Computers</a> &#8594;</li>
              <li>Laptops</li>
            </ul> 
          </nav>

この例に対する CSS

コード例:

 
      nav, h2, ul, ul li{ display: inline;}
      nav > h2{ font-size: 1em; } 
      ul { padding-left: 0em; }

実装例: Breadcrumb example

参考リソース

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

HTML5 Bread crumb navigation

訳注: パンくずリスト | 検索 | Google Developers 及び Markup: Breadcrumbs - Bing Webmaster Tools もあわせて参考になる。

検証

手順

ウェブページ一式の中にパンくずリストが実装されているとき:

あるウェブページに移動する。
パンくずリストが表示されていることを確認する。
パンくずリストが、現在位置に達する正しいナビゲーションの順序、又はサイト構造内の現在位置までの正しい階層の経路を表示していることを確認する。
現在位置を含んでいないパンくずリストの場合:
1. パンくずリストのすべての要素がリンクとして実装されていることを確認する。
現在位置を含んでいるパンくずリストの場合:
1. 現在位置を除くすべての要素がリンクとして実装されていることを確認する。
2. 現在位置がリンクとして実装されていないことを確認する。
すべてのリンクが、パンくずリストによって指定された正しいウェブページへ移動することを確認する。

期待される結果

パンくずリストを使用している一連のすべてのウェブページについて:
- 2.、3.、及び 6.の結果が真である。
- その上で、4.又は 5.のいずれかが真である。

G68: ライブの音声のみのコンテンツ及びライブの映像のみのコンテンツの目的を説明するために、簡潔なテキストによる代替を提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

解説

この達成方法は、ライブの音声しか含まない、及びライブ映像しか含まないコンテンツに対して、簡潔なテキストによる代替を提供するものである。このテキストは、音声の場合は時間の経過に伴って変化するメディア (音声または映像) の完全なテキストによる代替、又は映像の音声解説と組み合わせて使用することもできる。ただし、そういった代替コンテンツは、この達成方法には含まれていない。この達成方法の目的は、利用者が非テキストのコンテンツにアクセスできないとしても、それが何であるかを判断できるようにすることである。注記: 完全な代替コンテンツがほかに提供されている場合でも、利用者が非テキストのコンテンツに遭遇する際は、それを特定できるようにしておくことが重要である。これにより、利用者は混乱せず、非テキストのコンテンツに遭遇した時点で、それを完全な代替コンテンツと関連付けられるようになる。

事例

事例 1

東海岸ハイウェイを映したライブ映像のフィードに、「東海岸ハイウェイ I-81 号線インターチェンジ南側のライブ映像で、現在の道路状況を放映中」とその内容を説明したラベルが付けられている。
ミシシッピ州議会のライブ音声フィードに、「ミシシッピ州議事堂内のマイクロフォンからのライブ音声」と、その内容を説明したラベルが付けられている。

参考リソース

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

G100: 非テキストコンテンツの一般に認められた名前 (name) 又は説明的な名前となる簡潔なテキストによる代替を提供する

検証

手順

非テキストコンテンツを取り除くか、非表示にするか、又は覆い隠す。
簡潔なテキストによる代替を表示する。
たとえコンテンツが失われたとしても、非テキストコンテンツの目的が明らかであることを確認する。

期待される結果

3. の結果が真である。

G69: 時間依存メディアに対する代替コンテンツを提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、同期したメディアの提示により伝えられている情報を提示するアクセシブルな代替方法を提供することである。

同期したメディアの提示において、情報は次のようにさまざまな方法で提示される。

発話 (会話)
音 (自然な音または人工的な音)
場面や背景
人や動物などの行動及び表情
テキスト又はグラフィック
その他

これらと同じ情報をアクセシブルな形式で提示するために、この達成方法には、同期したメディアと同じ物語や同じ情報を伝える文書を作成することが含まれている。この種の文書は、脚本と呼ばれることがある。この文書には、重要な会話や行動のほか、物語の一部となっている背景などの説明が全て含まれる。

同期したメディアを最初に作成する際に実際の脚本が使われたのであれば、これが代替コンテンツの元素材となりうる。ただし、制作や編集の過程で、同期したメディアは通常、脚本とは異なるものに変更される。この達成方法では、同期したメディアの最終版での実際の会話や内容に合わせて、オリジナルの脚本を変えることになる。

さらに、同期したメディアのタイプによっては、同期したメディアの再生時に特定の個所で起きるインタラクションが含まれることがある。場合によっては、アクション (何かを購入する、送信する、実行するなど) が起きるなどして、同期したメディアの進行に影響すること (同期したメディアが、利用者の入力によって決まる複数のパスを持っている場合など) もある。このような場合は、時間の経過に伴って変化するメディアの代替コンテンツにもリンク又は何らかのメカニズムを提供して、その代替コンテンツの利用者が、同期したメディアの利用者と同じ選択肢から選べ、同じことができるようにする。

事例

新しい機器の使い方を従業員に示す研修フィルムで、1 人の人が使い方を実演しながら、同時に説明している。この研修フィルムを制作した際に使った脚本が代替コンテンツの元素材として使用されていて、実際の発話内容などに合わせて編集及び変更されている。研修ビデオと、時間の経過に伴って変化するメディアの代替コンテンツは、この会社のウェブサイトで公開されている。従業員は、機器の使い方を学ぶにあたって、このどちらか一方、あるいは両方を使うことができる。
インタラクティブなショッピング環境で、利用者がバーチャル店舗を操作して買い物できるようになっている。時間の経過に伴って変化するメディアの代替コンテンツでは、利用者がバーチャルショッピングカートに品物をドラッグするのではなく、リンクを含むテキストで提供された同じショッピングのコンテンツにアクセスして、商品陳列棚の列を選び、商品を購入できるようになっている。

参考リソース

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

検証

手順

時間依存メディアに対する代替を参照しながら、同期したメディアによる提示を閲覧する。
時間依存メディアに対する代替での会話が、同期したメディアによる提示での会話と一致していることを確認する。
時間依存メディアに対する代替に、音の説明があることを確認する。
時間依存メディアに対する代替に、場面及び場面の変更の説明があることを確認する。
時間依存メディアに対する代替に、「当事者」(人、動物など) の行動及び表現の説明があることを確認する。
代替版が別のページにある場合、利用者が別の版に到達できるリンクが利用可能かどうかを確認する。

期待される結果

2.、3.、4. 及び 5. の結果が真である。

G70: オンライン辞書を検索する機能を提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、オンライン辞書にアクセスするメカニズムをウェブページに加えることで、語句や専門用語の定義、略語の説明を提供することである。この達成方法では、コンテンツ制作者に対してサイト内に用語集や他のメカニズムを用意することを求めているのではなく、ウェブにすでに存在するリソースの利用を示している。ウェブページからオンライン辞書へのアクセス手段を提供することで、利用者は求める定義の所在が簡単に分かる。そのオンライン辞書が正しい定義を提供している場合にのみ、この達成方法を用いることができる。

事例

事例 1

コンピュータがどのように動作するかを説明したサイトで、各ページに検索機能を設置した。この検索には、コンピュータ用語、頭字語、省略語に関するオンライン辞書を利用している。辞書はコンピュータ用語に特化したものであるため、検索にヒットした頭字語の説明は、一般的な辞書よりも正確であるべきである。

事例 2

ある英文法のオンライン授業では、新しい単語を紹介するテキストのパラグラフを提供している。各単語はオンライン辞書へのリンクとし、その単語の定義が分かるようにしてある。リンクを動作させるとオンライン辞書が新しいウィンドウで開き、単語とその定義が表示される。

参考リソース

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

検証

手順

定義される各単語、語句、又は略語について:

単語、語句、又は略語をオンライン辞書で検索するためのメカニズムがウェブページ内に存在することを確認する。
単語、語句、又は略語の検索結果が正しい定義であることを確認する。

期待される結果

1. 及び 2. の結果が真である。

G71: すべてのウェブページにヘルプへのリンクを提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 3.3.5 (ヘルプ)
- クイックリファレンス 3.3.5 (ヘルプ)
- 達成基準 3.3.5 (ヘルプ)を理解する

解説

この達成方法の目的は、各ウェブページに少なくとも１つのヘルプ情報へのリンクを用意して、利用者がフォームにデータを入力する際に、状況依存のヘルプを提供することである。リンクは、そのウェブページのための情報があるヘルプページへ遷移する。もう一つの方法は、インタラクティブなコントロールのひとつひとつにヘルプページへのリンクを提供する。このリンクを当該コントロールのすぐ前か後に配置することで、そのコントロールで問題があった場合、利用者が簡単にそのリンクまでタブで移動することができる。そのヘルプ情報をブラウザの新しいウィンドウで表示することで、それまでにフォームに入力されたデータは失われずに済む。注記: リンクがヘルプ情報を提供する唯一の手段ではない。

事例

事例 1

下記の達成方法の例は、ヘルプ情報へのリンクを含んだラベル要素を示している。ラベル要素内にヘルプ情報へのリンクを置く事で、スクリーンリーダーの利用者が入力フォームのコントロールを利用する際にヘルプのリンクにアクセスすることが可能になる。

コード例:


              <form action="test.html">
                <label for="test">Test control
                <a href="help.html" target="_blank">Help</a></label>
                <input type="text" name="test" id="test" />
                </form>

検証

手順

フォームが含まれるウェブページを特定する。
そのページのフォームの全て記入する方法を説明する情報の役に立つようなリンクが一つ以上存在するかどうかを判断する。
インタラクティブなコントロールの前、又は後ろに、そのコントロールに特有な情報へのリンクがあるかどうかを判断する。

期待される結果

2. 又は 3. のいずれかの結果が真である。

G73: 非テキストコンテンツのすぐ隣に別の場所へのリンクを置き、その別の場所で長い説明を提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する
注記: この達成方法は、達成基準 1.1.1 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.1.1 を理解するを参照すること。

解説

この達成方法の目的は、長い説明文を直接組み込む機能 (例: HTML の longdesc 属性) を持たない、又はサポートされないことが確認されているウェブコンテンツ技術において、離れた場所にある長い説明文へのリンクを提供することである。

この達成方法によって、長い説明文が非テキストコンテンツとは別の場所に提供される。同じ URI の中の異なる場所、又は別の URI の場合もある。長い説明文へのリンクが非テキストコンテンツに近接して提供されるが、そのリンクは非テキストコンテンツの直前又は直後に提供できる。もし説明が他のテキストと一緒に配置されているならば、どこで読み終えてメインコンテンツに戻るかがわかるように最後に「説明の終わり」と入れる。「戻る」ボタンでジャンプしてきた場所に戻れない場合は、その非テキストコンテンツに戻るためのリンクを提供する。

この達成方法は、longdesc 属性が HTML の仕様に加えられる以前に一般的に使用されていた。HTML では、通常、画像の隣に D を配置して長い説明文へのリンクとして実装していたため D リンクと呼ばれていた。この達成方法は技術に依存していないため、リンクをサポートするあらゆるウェブコンテンツ技術で利用できる。

事例

事例 1: 棒グラフ

ウェブページに上位 3 名の販売員の売上げを示した棒グラフがある。

それには簡潔なテキストによる代替があり、「上位 3 名の販売員の 10 月の売上げ表」と書かれている。

非テキストコンテンツの直後には長い説明文を示唆する小さな画像がある。その画像に対する代替テキストには「グラフの詳細な説明」と書かれている。画像は「このページのグラフの説明」という表題がつけられたページ下部のセクションへのリンクになっている。リンクは次のような具体的な説明を指している:「10 月の売上げはメアリーが 400 個でトップ、マイクが 389 個の僅差で続いており、クリスが 350 個でトップ 3 の最後となっている。[説明の終わり]」

事例 2: 棒グラフ -ユーザエージェントの「戻る」がセキュリティ上の理由からサポートされていない非 HTML 技術の場合

ウェブページ上に上位 3 名の販売員を表示した棒グラフがある。

それには簡潔なテキストによる代替があり、「上位 3 名の販売員の 10 月の売上げ表」と書かれている。

非テキストコンテンツの直後には長い説明文を示唆する小さな画像がある。その画像に対する代替テキストには「グラフの詳細な説明」と書かれている。その画像は「10 月の売上げ報告にあるグラフの説明」というタイトルの別のページへリンクとなっている。その説明へのリンクは次のような具体的な説明を指している:「10 月の売上げはメアリーが 400 個でトップ、マイクが 389 個の僅差で続いており、クリスが 350 個でトップ 3 の最後となっている。説明の終わり。<link> 売上げグラフに戻る</link>」

事例 3: リンクとして使用されるキャプション

グラフがある。グラフの直下にある図表のキャプションが詳細な説明へのリンクとなっている。リンクの title 属性により、詳細な説明へのリンクであることが明確になっている。

事例 4: 音声しか含まないファイルのトランスクリプト

マーチンルーサーキングのスピーチの録音記録がある。音声ファイルへのリンクとその内容をテキストに書き起こしたトランスクリプトへのリンクが隣同士にある。

参考リソース

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

検証

手順

非テキストコンテンツの直前又は直後のリンクの存在を確認する。
この特定の非テキストコンテンツの長い説明を直接指し示す有効なリンクであることを確認する。
長い説明が非テキストコンテンツと同じ情報を伝達していることを確認する。
利用者が非テキストコンテンツの元の場所に戻るためのリンク又は「戻る」機能の可用性を確認する。

期待される結果

上記の四つ全ての結果が真である。

G74: 短い説明の中で長い説明のある場所を示して、非テキストコンテンツの近くにあるテキストで長い説明を提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する
注記: この達成方法は、達成基準 1.1.1 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.1.1 を理解するを参照すること。

解説

この達成方法の目的は、利用者を別の場所にジャンプさせることなく長い説明文を提供することである。非テキストコンテンツの内容の一部が失われる恐れがある利用者にとって有益な説明文が、すべての利用者にも見られるようになる。

この達成方法によって、長い説明文が標準の提示の一部として提供される (つまり、すべての利用者が受け取ることができる)。説明文は非テキストコンテンツの近くに配置されるが、隣接させる必要はない。例えばグラフの下にキャプションがあり、長い説明文が次の段落で提供されているといった場合である。

非テキストコンテンツを閲覧できないときに、どこを探せば良いかわかるように、簡潔なテキストによる代替の中に長い説明文の場所を示す。

事例

事例 1: 棒グラフ

ウェブページに上位 3 名の販売員の売上げを示した棒グラフがある。

簡潔なテキストによる代替では「上位 3 名の販売員の 10 月の売上表。グラフに続いてテキストの詳細」と書かれている。

次の説明文が棒グラフの直下の段落にある。「10 月の売上げはメアリーが 400 個でトップ、マイクが 389 個の僅差で続き、クリスが 350 個でトップ 3 の最後となっている。」

参考リソース

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

検証

手順

簡潔なテキストによる代替に長い説明文の場所が含まれていることを確認する。
長い説明文が視覚的にも音声読み上げ順序でも非テキストコンテンツの近くにあることを確認する。
長い説明文が非テキストコンテンツと同じ情報を伝達していることを確認する。

期待される結果

上記の三つ全ての結果が真である。

G75: コンテンツの更新を延期するメカニズムを提供する

適用 (対象)

自動更新するコンテンツ

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.4 (割り込み)
- クイックリファレンス 2.2.4 (割り込み)
- 達成基準 2.2.4 (割り込み)を理解する

解説

この達成方法の目的は、利用者がコンテンツの自動更新や他の緊急ではない中断を延期できるようにすることである。設定を通じて、又は更新の直前に警告し、利用者が更新を停止できることによって、このことが実現できる。設定を提供できる場合、コンテンツの自動更新は初期状態では無効にし、利用者が自動更新の頻度を設定できるようにするとよい。

事例

あるウェブページは株価を提供し、時々自動的に更新される。このページでは、小さなフォームで「データの更新頻度 (分)」というフィールドが提供されており、利用者は更新頻度を調整できる。

検証

手順

自動的に更新するコンテンツのあるページを見つける。
自動更新に対して、自動更新のタイミングを調整するメカニズムを探す。
自動更新がデフォルトで無効になっている、又は自動更新が発生する前に利用者に警告されて停止できることを確認する。

期待される結果

3. の結果が真である。

G76: 自動的に更新する代わりに、利用者がコンテンツの更新を要求するメカニズムを提供する

適用 (対象)

自動更新をサポートする全てのウェブコンテンツ技術又はウェブコンテンツ技術の組み合わせ

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、ページの自動的な再読み込みによって状況が変化し、利用者が混乱したり位置が分からなくなったりすることを避けるために、コンテンツの更新やそのタイミングを利用者がコントロールできるようにすることである。自動更新によって何が起こるのかが明らかになっていないと、スクリーンリーダーの利用者が混乱してしまう恐れがある。ページ上で利用者の現在位置を示すスクリーンリーダーの「バーチャルカーソル」は、ページが再読み込みされるとページの最上部に移動してしまう。また、画面拡大ソフトウェアの利用者や読字障害のある利用者も、ページの自動的な再読み込みによって現在位置が分からなくなってしまう恐れがある。

コンテンツの中には、頻繁に新たなデータや情報に更新するものがある。また、開発者は、コンテンツがサーバーに自分自身の新しいコピーを要求するコードを挿入し、自動更新を強いることがある。そのような更新やその頻度は、常に利用者のコントロール下にあるわけではない。コンテンツ制作者は、自動更新の仕組みを埋め込むのではなく、利用者が必要な場合にコンテンツを更新できるメカニズムを提供すべきである。

事例

事例 1

HTML では、利用者がコンテンツを更新するボタン又はリンクを、開発者が提供できる。例えば、次のコード例のように、ページ上で http://www.example.com/news.jsp にニュース項目があると示すことである。

コード例:


              <a href="news.jsp">Update this page</a>

事例 2

E メールのウェブインタフェース (ウェブメール) では、自動更新ではなく、新しいメールを確認するボタン又はリンクを、開発者が提供できる。

参考リソース

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

検証

手順

コンテンツを更新するメカニズムを見つける (そのようなメカニズムが存在する場合)。
そのような各メカニズムについて、利用者が更新を要求できるかどうかを確認する。
そのような各メカニズムについて、自動更新を引き起こされうるかどうかを確認する。

期待される結果

2. の結果が真の場合、3. の結果が偽である。

G78: 音声解説を含んだ、利用者が選択可能な副音声トラックを提供する

適用 (対象)

音声トラック及び視覚的なコンテンツのあるウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、視覚的に提供される情報の音声 (話し言葉) バージョンを提供することで、目で見ることのできない利用者が視聴覚コンテンツを理解できるようにすることである。

今日のユーザエージェントのほとんどは複数の音声トラックを一つにまとめることができないため、この達成方法では、オリジナルの音声トラックを付加的な音声解説の入った別の音声トラックに置き換える選択肢を利用者に提供することによって、音声による追加の情報を同期したメディアに追加する。この追加された情報は、コンテンツを理解するにあたって重要な行動、登場人物、場面の変化、及びスクリーン上のテキスト (キャプション以外の文字) などに焦点を当てたものである。

この新しい情報によって、オリジナルの音声トラックに含まれた重要な音声情報が分かりにくくなってしまう (または、うるさい効果音によって新しい情報が不明瞭になってしまう) のでは役に立たないため、新しい情報は会話や効果音の合間に追加される。このため、コンテンツに追加できる情報の量は限られることになる。

(視覚的に伝えられている情報の) 音声解説を提供する音声トラックは、利用者が選択できる代替の音声トラックとするか、又は全ての利用者が聞く標準の音声トラックとすることができる。

事例

北東部地域の旅行ビデオで、会話の合間に追加された音声解説があり、全盲の利用者が登場人物の話していることを随時理解できるようになっている。
キツツキが木をつついて巣を作る様子を示したビデオがある。利用者がコンテンツ内のボタンを押すと、音声解説を提供するトラックのオン/オフが切り替えられるようになっている。
講義のビデオで、講師が「これが最も重要です」などの表現をした個所すべてに、音声解説が付加されている。この音声解説により、ビデオを見ることができず聞くだけの利用者にも、「これ」が何を指すのかが分かるようになっている。
映画のファイルに二つの音声トラックがあり、片方に音声解説が含まれている。利用者は、メディアプレーヤーでトラックを選択することにより、この映画を観賞する際の音声トラックを選ぶことができる。

参考リソース

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

検証

手順

音声解説を含む音声トラックをオンにする機能が存在することを確認する。例えば、コンテンツ自体にあるコントロールを用いることによって、又はメディアプレーヤーもしくは OS でのコントロールもしくは設定によってなど。
同期したメディアの音声を聞く。
発話の合間が視覚的なコンテンツに関する重要な情報を伝えるために使用されているかどうかを確認する。

期待される結果

1. 及び 3. の結果が真である。

G79: テキストの音声バージョンを提供する

適用 (対象)

音声フォーマットへのリンクをサポートするウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.5 (読解レベル)
- クイックリファレンス 3.1.5 (読解レベル)
- 達成基準 3.1.5 (読解レベル)を理解する

解説

書かれたテキストの言葉を読んで理解するのが難しい利用者には、テキストの音読を聞くのが非常に役立つことがある。現在このような代替版は、録音した肉声又は合成音声を用いて提供できる。例えば、コンテンツ制作者がテキストを合成音声に変換し、その音声バージョンを音声ファイルとして保存できる製品がたくさんある。音声バージョンへのリンクは、コンテンツ内で提供すればよい。制作コストは、使用する声の品質や、テキストを頻繁に変更するかどうかによって異なる。

短いテキスト及び静的なテキストコンテンツの音声バージョン
この方法は、量の少ないテキストや、めったに変更しない文書に効果的である。
1. 誰かがテキストを読み上げたものを録音するか、又は個々の文書や一部の段落を合成音声に変換するツールを利用する。できれば、最も聞き取りやすく、魅力的な声を採用するのがよい。
2. 音声バージョンを音声ファイルとして保存する。その際、広く利用されていて、多くのメディアプレーヤーがサポートしている音声フォーマットを用いる。
3. 音声バージョンへのリンクを提供する。
4. 音声フォーマットを明記する (例えば、.MP3、.WAV、.AU など)。
5. そのフォーマットをサポートしているメディアプレーヤーへのリンクを提供する。
よく変更するテキストの音声バージョン
ページをよく変更する場合や、利用者の選択によってテキストコンテンツが変わる場合は、サーバーサイドで処理する方法が最もよいだろう。サーバーサイドで処理するツールの中には、利用者が興味のあるテキストを選択し、聞くことができるものがある。通常は、利用者がテキストから音声への変換を開始するボタンを押せば読み上げられる。

事例

事例 1: 政府機関のウェブサイト

ある公営住宅機構のウェブサイトには、全てのページに「このページを読み上げる」というボタンがある。利用者がボタンを選択すると、そのページが合成音声で読み上げられる。

参考リソース

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

(今のところ、なし。)

検証

手順

コンテンツの音声版が利用できるかどうかを確認する。

期待される結果

1. の結果が真である。

G80: コンテキストの変化を開始する送信ボタンを提供する

適用 (対象)

フォームを含むコンテンツ

これは、次の達成基準に関連する達成方法である:

達成基準 3.2.2 (入力時)
- クイックリファレンス 3.2.2 (入力時)
- 達成基準 3.2.2 (入力時)を理解する

解説

この達成方法の目的は、利用者が明示的にコンテキストの変化を要求できるメカニズムを提供することである。なぜなら、想定される送信ボタンの使用法は、フォームに入力されたデータを送信する HTTP リクエストを生成するというものであり、これはコンテキストの変化をもたらすために使用する適切なコントロールで、利用者を混乱させないようにするための実践例であるからである。

事例

事例 1

コンテキストの変化が起こるフォームで送信ボタンが使用されている。

参考リソース

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

検証

手順

コンテンツの中から全てのフォームを見つけ出す。
それぞれのフォームに送信ボタンがあることを確認する。

期待される結果

2.の結果が真である。

G81: プレーヤーによって別のビューポートに表示する、又は画像上に重ねることのできる、手話通訳の同期した映像を提供する

適用 (対象)

複数の映像ストリームの同期が可能な、同期したメディアに関する全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 1.2.6 (手話 (収録済) )
- クイックリファレンス 1.2.6 (手話 (収録済) )
- 達成基準 1.2.6 (手話 (収録済) )を理解する

解説

この達成方法の目的は、耳の聞こえない又は、テキストを速く読むことができない利用者が、全ての利用者に向けたコンテンツの提示に影響を与えずに、同期したメディアによるコンテンツにアクセスできるようにすることである。

この達成方法は、元の映像ストリームに同期した、別の映像ストリームとして手話通訳を提供することによって実装可能である。プレーヤーに依存するが、この補助的な映像ストリームは、元の映像の上に重ねる又は別ウィンドウに表示させることができる。また元の映像から手話通訳を分離して拡大させることができ、手話者の手や体及び表情の動きを見やすくすることができる。

注記: 一般的に、手話は単に墨字を符号化したものではないため、コンテンツ制作者は複数種類あるうちのどの手話を用いるかを決めなければならない。通常は主な利用者が使用している手話を用いる。さまざまな利用者を想定する場合は、複数の手話を用いる。複数の手話のための推奨達成方法を参照のこと。

訳注: 注記に記載されている達成方法はまだ文書化されていない。

事例

事例 1

大学では、あらゆる教育プログラムに同期した映像ストリームの手話通訳を提供していて、閲覧者の選択によって表示させることができる。

参考リソース

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

手話を作成するための指針
- "Sign Language presentation" では、手話通訳者を撮影する際の留意点の概要を知ることができる。元の素材が書き言葉の場合と話し言葉の場合の両方についての議論も含まれている。
- 撮影のテクニックについては chapter 12, “Filming the Signer(s)" で考察されている。
- オリジナルの同期したメディアコンテンツに関連して手話通訳を表示させる方法についての有益な情報は Chapter 13, "Editing" で提供されている。
  注記: これらの達成方法はウェブベースの提示にも適用される必要がある。

検証

手順

プレーヤーで手話ウィンドウの表示を有効にする。
耳が聞こえて、使用されている手話に精通した人にプログラムを見せる。
手話通訳が画面上又は別ウィンドウに表示されているかどうかを確認する。
会話及び重要な音が手話通訳によって伝達され、音に同期していることを確認する。

期待される結果

3.及び 4.の結果が真である。

G82: 非テキストコンテンツの目的を特定するテキストによる代替を提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

解説

この達成方法の目的は、非テキストコンテンツの完全な機能を提供できないとしても、テキストによる代替を介して有用な情報を提供することである。

テキストによる代替は、時として、オリジナルの非テキストコンテンツとまったく同じ目的には使えないことがある (例えば、2 次元で素早く標的を定めるスキルや目と手の連動スキルを開発するためのアプレットなど)。そういったケースでは、この達成方法を用いて、非テキストコンテンツの目的を説明する。

事例

事例 1

目と手のコーディネーションスキルを開発するためのアプレットに、「マウスと動く標的を使用して目と手の連動スキルを開発するアプレット」というテキストによる代替が付けられている。
丸いディスクの端を押してリモートカメラを制御し、真ん中のスライダーを使ってズームを調整するカメラのアプレットに、「リモートビデオカメラの照準とズームのコントロール」というテキストによる代替が付けられている。

参考リソース

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

検証

手順

非テキストコンテンツを取り除く、非表示にする、又は覆い隠す。
非テキストコンテンツをテキストによる代替に置き換える。
たとえ機能が失われたとしても、非テキストコンテンツの目的が明確であることを確認する。

期待される結果

3. の結果が真である。

G83: 入力が完了していない必須項目を特定するために、テキストの説明を提供する

適用 (対象)

利用者の入力が必須の項目があるコンテンツ

これは、次の達成基準に関連する達成方法である:

達成基準 3.3.1 (エラーの特定)
- クイックリファレンス 3.3.1 (エラーの特定)
- 達成基準 3.3.1 (エラーの特定)を理解する
達成基準 3.3.3 (エラー修正の提案)
- クイックリファレンス 3.3.3 (エラー修正の提案)
- 達成基準 3.3.3 (エラー修正の提案)を理解する
達成基準 3.3.2 (ラベル又は説明)
- クイックリファレンス 3.3.2 (ラベル又は説明)
- 達成基準 3.3.2 (ラベル又は説明)を理解する
注記: この達成方法は、達成基準 3.3.2 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 3.3.2 を理解するを参照すること。

解説

この達成方法の目的は、入力の必要な項目が未入力であることを利用者に知らせることである。利用者が必須のフォーム項目に入力しなかった場合には、どの項目を入力しなかったのかが利用者に分かるように、その情報をテキストで提示する。一つのアプローチとして、クライアントサイドでのバリデーションを用いて、未入力のままになっている必須項目を特定するアラートのダイアログボックスを提供する方法がある。また、もう一つのアプローチとしては、サーバーサイドでのバリデーションを用いて、フォームを再表示し (すでに入力されたデータも含む)、未入力のままになっている必須項目の場所にテキストでの説明を入れるか、テキストでの説明文によって未入力のままになっている項目を特定する方法がある。

注記: エラーが起きたことに気づかぬまま、フォームが正常に機能していないと仮定する利用者もいるので、メッセージやアラートを提示するのは良い方法である。また、ページタイトル (title 要素) でエラーを知らせるのも、良い方法である。なぜならスクリーンリーダーの利用者は、新しいページが返ってくるやいなや、そのページのメインコンテンツエリアを読むことなく、ページが正常に送信されたと信じて別のページに遷移しがちだからである。

事例

利用者がフォームを送信しようとするが、一つ以上の必須項目で、入力又は選択しなかった項目がある。クライアントサイドでのバリデーションによって、この未入力項目が検出されると、必須項目が未入力であることを利用者に知らせるアラートのダイアログが表示される。問題が検出された項目のラベルは、送信ボタンが押された後、問題となっている項目を特定するように変更され、その項目へのリンクが文書に挿入されて、利用者はそのアラートのダイアログを閉じた後、その項目へ移動できるようになっている。
利用者がフォームを送信しようとするが、一つ以上の必須フィールドで入力の提供または選択肢の選択を忘れている。クライアントサイドのバリデーションを使用して、漏れが検出され、必須フィールドが完了していないことをユーザーに知らせる警告ダイアログが表示される。この問題のあるフィールドのラベルが問題のフィールドの特定により変更され、問題のフィールドへのリンクが送信ボタンの後ろへ文書に挿入されるため、利用者はアラートを閉じた後に移動できる。
利用者が、必須項目のあるフォームを記入している。それぞれの項目が必須かどうかは、項目のラベルで示されている。利用者が Tab キーを使って必須項目へ移動し、データ入力や選択をせずにその項目から出ると、クライアントサイドのスクリプトが項目のラベル部分を変更して、その項目を空白のままにしておくことはエラーであると伝える。
注記: スクリーンリーダーのなかには、このようなラベルの変更に気付かず、読み上げないものがあるため、スクリーンリーダーの利用者はエラーに気がつかないことがある。

G85: 利用者の入力が要求されたフォーマット又は値の範囲外の場合に、テキストの説明を提供する
SCR18: クライアントサイドのバリデーション及びアラートを提供する
エラーを知らせる情報をページタイトルに含める。(リンク追加予定)

検証

手順

一つ以上の必須フィールドへの入力を意図的に空白のままにして、フォームを記入して送信する。
未入力のままになっている必須フィールドを特定するテキストによる説明が提供されていることを確認する。
再表示のためにデータを保持することが不適切なセキュリティに関連するフィールドにデータ (例: パスワード) がない限り、利用者によって入力済みの他のデータが再表示されていることを確認する。

期待される結果

2. 及び 3.の結果が真である。

G84: 利用者が許可された値のリストにない情報を与えた場合に、テキストの説明を提供する

適用 (対象)

限定された値の入力のみを受け付けるコンテンツ

これは、次の達成基準に関連する達成方法である:

解説

この文書の目的は、利用者による入力がバリデートされた結果、エラーが検出された場合に、そのエラーの内容を、利用者がアクセスできる方法で説明することである。一つのアプローチとして、利用者がフォームを送信しようとするときに、エラーのある項目を説明したアラートのダイアログを提示する方法がある。また、もう一つのアプローチとしては、バリデーションがサーバーサイドで行われるのであれば、(利用者が入力した項目のデータは残した状態で) フォームを再表示し、ページの上部にテキストでの説明文を表示して、バリデーションで問題が発見されたことを知らせるとともに、その問題の内容を説明して、利用者が問題のあった項目を簡単に見つけられる方法を提供することがある。達成基準に「テキストで」と書かれているのは、項目のラベルにアスタリスクを付けたり、ラベルのテキストを赤色に変えたりしてエラーがあることを示すだけでは十分でないことを強調している。つまり、エラーであることの説明文をテキストで提供すべきである。

利用者による入力内容が、許可された値のいずれかでなければならない場合は、テキストでの説明文によってそのことを示すべきである。そして、可能であれば、許可された値のリストを示す、又は入力値に最も近い許可値を提示するとよい。

事例

利用者がフォーム項目に無効なデータを入力している。そのフォームを送信しようとすると、アラートのダイアログが表示されて、エラーの内容が説明され、利用者はそのエラーを修正することができる。
利用者がフォーム項目に無効なデータを入力して、そのフォームを送信すると、サーバーがフォームを利用者に再提示する。利用者の入力したデータはそのまま表示された状態で、ページの上部に入力エラーがあったことをテキストで明確に示している。このテキストは、エラーの内容を説明していて、どの項目に問題があったのかを明確に示しているため、利用者はその項目へ容易に移動し、問題を修正することができる。

検証

手順

フォームフィールドに無効なデータを入力する。
問題点に関して情報がテキストで提供されていることを確認する。

期待される結果

2. の結果が真である。

G85: 利用者の入力が要求されたフォーマット又は値の範囲外の場合に、テキストの説明を提供する

適用 (対象)

利用者のデータ入力を受け付け、そのフォーマット、値及び／又は入力の種類に制限があるコンテンツ

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、利用者によって提供された情報が受け付けられない場合に、入力エラーの修正を支援することである。利用者による入力データをバリデートした結果、入力エラーが検出された場合に、この入力エラーの内容と場所に関する情報をテキストで提供することによって、利用者は問題のある箇所を特定することができる。一つのアプローチとして、クライアントサイドでのバリデーションを用いて、利用者が無効なデータを項目に入力すると、即座にエラーを説明するアラートのダイアログボックスを提示する方法がある。また、もう一つのアプローチとして、サーバーサイドでのバリデーションを用いて、フォームを再表示し (すでに入力されたデータも含む)、ページの上部にテキストでの説明文を表示して、エラーがあったことを知らせるとともに問題の内容を説明して、利用者が問題のあった項目を簡単に見つけられるような方法を提供することがある。

ただし、テキストでの説明は、どのように提供するとしても、次のいずれかの方法に則って、利用者を支援すべきである:

その項目における正しいデータ入力の例を示す
その項目における正しいデータ入力を説明する
利用者のデータ入力を踏まえ、それから推測できるそれに近い正しいデータ入力の値を示すことにより、正しい値を入力する方法について利用者に説明する。

事例

利用者が、フォーム項目に無効なデータを入力している。その項目から出ると、アラートのダイアログが表示されて、エラーの内容が説明され、利用者はエラーを修正することができる。
利用者がフォーム項目に無効なデータを入力して、そのフォームを送信すると、サーバーがフォームを利用者に再提示する。利用者の入力したデータはそのまま表示された状態で、ページの上部に入力エラーがあったことをテキストで明確に示している。このテキストは、エラーの内容を説明していて、どの項目に問題があったのかを明確に示しているため、利用者はその項目へ容易に移動し、問題を修正することができる。
利用者がフォーム項目に無効なデータを入力して、そのフォームを送信しようとする。クライアントサイドのスクリプトがエラーを検出し、送信をキャンセルした上で、そのフォームにエラーを説明するテキストとエラーのある項目へのリンクを表示する。また、このスクリプトは、問題のある項目のラベルを変更して、それを強調する。

SCR18: クライアントサイドのバリデーション及びアラートを提供する

検証

手順

フォームに記入し、要求されているフォーマット又は値以外の失敗する入力を故意に行う。
エラーになった項目を特定して、無効な入力の種類及びその修正方法に関する情報を提供する説明がテキストで提供されていることを確認する。
再表示のためにデータを保持することが不適切なセキュリティに関連するフィールド (例: パスワード) にデータがない限り、利用者によって入力済みの他のデータが再表示されていることを確認する。

期待される結果

2. 及び 3. の結果が真である。

G86: 前期中等教育レベルの読解力をもつ人が理解できるテキストの要約を提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.5 (読解レベル)
- クイックリファレンス 3.1.5 (読解レベル)
- 達成基準 3.1.5 (読解レベル)を理解する

解説

この達成方法の目的は、難解なコンテンツの要約を提供することである。要約は元のコンテンツに追加で提供する。

単語や文章の読解が難しいという障害のある利用者は、難解なテキストを読んだり理解するのに苦労することが多い。この達成方法は、コンテンツにおける最も重要なアイデアと情報を短い文章で提供するものである。読みやすい要約にするためには、元のコンテンツよりも短い文章にし、一般的な言葉を用いるとよい。

要約の作成には、次のステップを用いることができる:

コンテンツの中で最も重要なアイデアと情報を見出す。
それと同じアイデアと情報を表現すべく、より短い文章で、一般的な言葉を用いて、一つ以上のパラグラフを書く (パラグラフの数は、元の文章の長さによる)。
要約の読みやすさを評価する。
要約を編集する。長い文章を二つに分けたり、長い単語やなじみのない言葉はより短く一般的な用語に置き換えることを検討する。
必要であれば、3 と 4 を繰り返す。

事例

事例 1: 読みやすい要約をつけた技術記事

技術革新を説明した記事がある。記事タイトルの直後には、「要約」という見出しのついたセクションがある。要約に含まれる文章の平均的な長さは 16 語で (記事中の文章は 23 語である)、記事中の専門的な技術用語に代えて、短く一般的な言葉を用いている。そして、前期中等教育レベルを超えた読解力を必要としない、という読みやすさの基準を適用している。

参考リソース

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

検証

手順

補足コンテンツとして提供した要約それぞれについて:

その要約の読みやすさを評価する。
その要約が前期中等教育レベルを超えた読解力を必要としていないこと。

期待される結果

2. の結果が真である。

G87: クローズドキャプションを提供する

適用 (対象)

ユーザエージェントがクローズドキャプションをサポートしている音声/映像のウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 1.2.2 (キャプション (収録済) )
- クイックリファレンス 1.2.2 (キャプション (収録済) )
- 達成基準 1.2.2 (キャプション (収録済) )を理解する
達成基準 1.2.4 (キャプション (ライブ) )
- クイックリファレンス 1.2.4 (キャプション (ライブ) )
- 達成基準 1.2.4 (キャプション (ライブ) )を理解する
注記: この達成方法は、達成基準 1.2.4 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.2.4 を理解するを参照すること。

解説

この達成方法の目的は、聴覚に障害のある利用者、又は同期したメディアの発話の聞き取りに困難のある利用者に対して、コンテンツを目で見て、発話及び音が伝えている情報を読むための方法を提供する一方で、聴覚に障害のない人にはキャプションを見ることを強制しないようにすることである。この達成方法では、発話及び重要な音が伝えている情報を全てテキストに書き起こして、利用者の要求に応じてキャプションとして画面に表示させる。つまり、そのテキストは必要な時にだけ表示されることになる。そのためには、ユーザエージェントがキャプションをサポートしている必要がある。

注記: キャプションは、字幕とは異なる。字幕は、発話内容のみをテキストで提供するものであって、重要な音の情報を含まない。

事例

事例 1

耳の聞こえない利用者がインタラクティブな教材を使えるようにするため、大学の音声によるインタラクティブな教材すべてにキャプションが組み込まれ、キャプションをオンにするための手順説明が提供されている。

事例 2

メディア会社のオンライン映画すべてにキャプションが含まれていて、クローズドキャプションを実装できるフォーマットで提供されている。

事例 3

既存の映画に、同期情報を含む特別なキャプションファイルが提供されている。映画のウィンドウに同期したキャプションを、画面上の別ウィンドウで提供できるプレーヤーが使えるようになっている。

事例 4

ローカルニュースのビデオにキャプションが付けられていて、使用しているプレーヤーに応じて映像上又は別ウィンドウにキャプションを表示することができる。

参考リソース

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

キャプションのガイダンス

SMIL

その他のキャプション関連

National Center for Accessible Media

検証

手順

メディアプレーヤーのクロ―ズドキャプション機能をオンにする。
同期したメディアのコンテンツを見る。
(発話内容及び音の伝えている情報全ての) キャプションが表示されていることを確認する。

期待される結果

3. の結果が真である。

G88: ウェブページに説明的なタイトルを提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.2 (ページタイトル)
- クイックリファレンス 2.4.2 (ページタイトル)
- 達成基準 2.4.2 (ページタイトル)を理解する
注記: この達成方法は、達成基準 2.4.2 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 2.4.2 を理解するを参照すること。

解説

この達成方法の目的は、各ウェブページにコンテンツの内容が分かるページタイトルをつけることである。コンテンツの内容が分かるページタイトルがあると、利用者は目的のコンテンツを見つけたり、サイト内で現在位置を確認したり、コンテンツを見てまわったりすることができる。コンテンツの内容が分かるページタイトルによって、利用者は、どのようなウェブページを利用してるのかを容易に特定することができ、その上、別のウェブページに移動したときもすぐにそのことが分かる。また、タイトルにより、利用者は、コンテンツを読んだり、又は解釈したりしなくてもウェブページを特定することができる。また、正確で内容が分かるページタイトルが、サイトマップ又は検索結果のリストにあれば、利用者は必要とするコンテンツをより速く特定することができる。そして、コンテンツの内容が分かるページタイトルがリンクテキストに用いられていれば、利用者は興味のあるコンテンツに、より正確にたどり着くことができる。

各ウェブページのタイトルは次の要件を満たすべきである:

そのウェブページの主題を特定している。
例えば、スクリーンリーダーで読み上げている場合、又はサイトマップや検索結果一覧にある場合など、前後の文脈がなくても意味がわかるようになっている。
簡潔である。

次のようなページタイトルはさらに有益である。

どのサイト又は他のどのリソースに属しているかを特定している。
ウェブページが属するサイト又はその他のリソースの中において、他に同じものがない。

事例

事例 1: 最も重要な識別情報を初めに記載するページタイトル

大きな組織のあるグループによって公開されているウェブページがある。ウェブページのタイトルでは、最初に、ページの話題を特定して、次に、そのグループ名及び組織名を示している。

コード例:


              <title>Working with us: The Small Group: The Big Organization</title>

事例 2: コンテンツの内容が分かるページタイトルの付いた同期したメディアによる提示

2004 年の南アジアで発生した津波に関する同期したメディアの提示には、「2004 年の津波」というタイトルがつけられている。

事例 3: 三つの部分から成る、コンテンツの内容が分かるページタイトルが付与されたウェブページ

ウェブページでは、クローズドキャプションを作成するためのガイドラインと提案を提供している。そのウェブページは、大きいサイトの中の「サブサイト」である。ページタイトルはダッシュで三つの部分に分けて示されている。ページタイトルの最初の部分は組織名、二つ目はウェブページが属するサブサイト名、そして三つ目はウェブページ自体を特定している (具体例としては、WGBH – Media Access Group – Captioning FAQ を参照。)

事例 4: 新聞のウェブページ

今日の版のみを閲覧できるウェブサイトでは、そのウェブページに「全国のニュース、第一面」というタイトルがつけられている。異なる日の版を閲覧することできるウェブサイトでは、そのページタイトルを「全国のニュース、第一面、2005 年 10 月 17 日」としている。

参考リソース

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

H25: title 要素を用いて、ページタイトルを提供する

検証

手順

ウェブページにページタイトルがあることを確認する。
そのページタイトルが、ウェブページのコンテンツに関連していることを確認する。
そのページタイトルによって、ウェブページを特定できることを確認する。

期待される結果

上記全ての結果が真である。

G89: 期待されるデータ書式及び入力例を提供する

適用 (対象)

利用者から情報を集め、利用者が入力できる書式に制約のあるページ

これは、次の達成基準に関連する達成方法である:

達成基準 3.3.2 (ラベル又は説明)
- クイックリファレンス 3.3.2 (ラベル又は説明)
- 達成基準 3.3.2 (ラベル又は説明)を理解する
注記: この達成方法は、達成基準 3.3.2 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 3.3.2 を理解するを参照すること。
達成基準 3.3.5 (ヘルプ)
- クイックリファレンス 3.3.5 (ヘルプ)
- 達成基準 3.3.5 (ヘルプ)を理解する

解説

この達成方法の目的は、利用者が入力しなければならないデータ書式の制約を通知することによって、利用者が入力エラーを回避しやすくすることである。これは、書式の特徴を記述するか、入力データに求められる書式の例を提供することによって対処できる。

注記: 日付や時刻のように、様々な記述方法があるデータ書式については、利用者にとって最も入力しやすい書式を選択できるオプションを提供するとよい。

事例

事例 1

日付を入力する HTML のフォームコントロールでは、label 要素内において、入力する日付はアメリカ合衆国の多くの利用者が想定する月-日-年の書式ではなく、日-月-年の書式でなければならないことを示している。

コード例:


              <label for="date">Date (dd-mm-yyyy)</label>
                <input type="text" name="date" id="date" />

G184: フォーム又はテキストフィールド一式の先頭に、必須の入力を記述するテキストの説明を提供する

検証

手順

所定の書式でしか利用者の入力データを受け付けないフォームコントロールを特定する。
1.で特定した各フォームコントロールが、期待される書式情報に関する情報を提供しているかどうかを判断する。

期待される結果

2.の結果が真である。

G90: キーボードがトリガーとなるイベントハンドラを提供する

適用 (対象)

コンテンツに機能性を含んでいるウェブコンテンツ技術すべて

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、キーボード又はキーボードインターフェースを使用している利用者がコンテンツの機能にアクセスできるようにすることである。そのためには、キーボードではない UI のイベントによって引き起こされるすべてのイベントハンドラは、キーボードベースのイベントとも関連づける、又は、他のデバイス特有の機能によって提供された機能を遂行するために冗長なキーボードベースのメカニズムを提供する。

事例

事例 1: ドラッグ＆ドロップ機能 　写真のアプリケーションに、スライドショーのような提示のためにオンラインアルバム内で写真を並び替えることができるように「ドラッグ」及び「ドロップ」の機能がある。また、利用者がキーボードのみを用いて写真を選び、リスト内の適切な場所でアイテムを「切り取り」、「貼り付け」できる機能もある。
事例 2: 並び替え機能 　質問事項をドラッグで動かして調査票を作ることができるウェブアプリケーションには、テキストフィールドの付いた質問リストがあり、利用者が質問番号を入力することによって、必要に応じて質問事項を並び替えることができる。

参考リソース

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

検証

手順

すべての機能がキーボードだけを使ってアクセスできることを確認する。

期待される結果

1.の結果が真である。

G91: リンクの目的を説明したリンクテキストを提供する

適用 (対象)

リンク機能を含む全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、リンクの目的をリンクテキストで説明することである。その説明により、利用者はこのリンクとウェブページ内にある他のリンクへのリンクとの違いを区別でき、利用者がリンクをたどるかどうかを決定するのを助ける。一般的に、遷移先の URI ではそのリンクの目的を説明したことにならない。

事例

事例 1: HTML において、a 要素のテキストコンテンツを用いてリンクの目的を説明する。

コード例:


              <a href="routes.html">
                Current routes at Boulders Climbing Gym
                </a>

参考リソース

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

H30: a 要素のリンクの目的を説明するリンクテキストを提供する

検証

手順

この達成方法を用いるコンテンツ内の各リンクに対して:

リンクテキストがそのリンクの目的を説明していることを確認する。

期待される結果

上記の結果が真である。

G92: 非テキストコンテンツに対して、それと同じ目的を果たし、かつ同じ情報を示す長い説明を提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する
注記: この達成方法は、達成基準 1.1.1 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.1.1 を理解するを参照すること。

解説

この達成方法の目的は、短いテキストによる代替が十分ではないとき、もとの非テキストコンテンツと同じ目的を果たし、同じ情報を提示する長いテキストによる代替を提供することである。

短いテキストによる代替と組み合わせて、長い説明は非テキストコンテンツの代わりとすることができる。短い代替は非テキストコンテンツを特定し、長い代替が情報を提供する。非テキストコンテンツがページから取り除かれて、短い説明と長い説明に置き換えられたとしても、そのページは同じ機能と情報を提供していることになる。

テキストによる代替に何を記述するべきかを決める際には、次の質問が参考になる。

なぜこの非テキストコンテンツがここにあるのか？
どんな情報が提示されているのか？
どんな目的を果たしているのか？
もし非テキストコンテンツを使うことができないとき、同じ機能又は情報を伝えるためにどのような言葉を使えばよいか？

事例

事例 1

10 月の売り上げを示すグラフには「10 月の売上グラフ」という短いテキストによる代替がついている。長い解説は「棒グラフは 10 月の売上を示している。6 人の営業がいて、マリアは 349 件でもっとも売上が高い。フランシスは次点の 301 件。その次は 256 件のジュアン、250 件のスー、200 件のリー、そして 195 件のマックスである。このチャートの第一使用目的はリーダーたちに見せるためのもので、そのためこの解説は売り上げ順になっている。」とする。

事例 2

過去 10 年の冬の平均気温を示している折れ線グラフには、「1996 年から 2006 年までの冬の平均気温」という短いテキストによる代替がある。長い解説には、折れ線グラフを生成するのに使ったデータデーブルが含まれている。

参考リソース

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

検証

手順

非テキストコンテンツを取り除くか、非表示にするか、覆い隠す。
長い説明を表示する。
長い説明が非テキストコンテンツによって伝えられた情報と同じ情報を伝えていることを確認する。

期待される結果

3.の結果が真である。

G93: オープン (常に見える) キャプションを提供する

適用 (対象)

(クローズドキャプションをサポートしていないものを含む) あらゆる同期したメディアのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 1.2.2 (キャプション (収録済) )
- クイックリファレンス 1.2.2 (キャプション (収録済) )
- 達成基準 1.2.2 (キャプション (収録済) )を理解する
達成基準 1.2.4 (キャプション (ライブ) )
- クイックリファレンス 1.2.4 (キャプション (ライブ) )
- 達成基準 1.2.4 (キャプション (ライブ) )を理解する
注記: この達成方法は、達成基準 1.2.4 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.2.4 を理解するを参照すること。

解説

この達成方法の目的は、聴覚に障害のある利用者や視聴覚コンテンツの発話の聞き取りに困難のある利用者に対して、コンテンツを目で見るための方法を提供することである。この達成方法では、発話及び重要な音が伝えている情報が全てテキストとして映像トラックに組み込まれる。つまり、テキストは常に表示されることになり、ユーザエージェントによるキャプションのサポートは特に必要としない。

注記: キャプションは、字幕とは異なる。字幕は、発話内容のみをテキストで提供するものであって、重要な音の情報を含まない。

事例

利用者がメディアプレーヤーでキャプションをオンにする方法を知らなくても、全ての利用者がオンライン映画を見られるようにするため、図書館協会では映像にキャプションを直接付けている。
報道機関が、全てのコンテンツにオープンキャプションを提供している。

参考リソース

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

G87: クローズドキャプションを提供する

検証

手順

クローズドキャプションをオフにした状態で同期したメディアを見る。
(発話内容及び重要な音の伝えている情報全ての) キャプションが表示されていることを確認する。

期待される結果

2. の結果が真である。

G94: 非テキストコンテンツに対して、それと同じ目的を果たし、かつ同じ情報を示す、簡潔なテキストによる代替を提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

解説

この達成方法の目的は、元の非テキストコンテンツと同じ目的及び情報を伝えるテキストによる代替を作成することである。その結果、非テキストコンテンツを取り除いてテキストによる代替で置き換えることができ、機能や情報が失われてしまうこともない。このテキストによる代替は、必ずしも非テキストコンテンツ自体について記述するとは限らない。同じ目的を果たし、同じ情報を伝達するべきである。結果的にテキストによる代替が非テキストコンテンツの説明のようになることがある。しかしながら、このケースは同じ目的を果たすための最善の方法である場合にのみ当てはまる。

可能であれば、簡潔なテキストによる代替は目的及び情報を完全に伝達すべきである。短いフレーズや文ではそれが不可能な場合は、簡潔なテキストによる代替でその情報の概要を提供すべきである。併せて長いテキストによる代替も使って情報の全てを伝達する。

テキストによる代替は非テキストコンテンツの代わりをすることができるべきである。非テキストコンテンツがページから削除され、そのテキストに置き換えられたとしても、そのページが同じ機能及び情報を提供する。テキストによる代替は簡潔で、できる限り有益な情報とする。

テキストにどのようなテキストを入れるか決める場合に、以下のような質問について考えるとよい:

なぜこの非テキストコンテンツがここにあるのか？
それはどのような情報を示しているのか？
それはどのような目的を果たすのか？
非テキストコンテンツを使用することができない場合、何という言葉を使って同じ機能及び／又は情報を伝達するか？

非テキストコンテンツがコンテンツを理解する上で重要な文言を含んでいる場合、代替テキストもその文言を含んでいるべきである。画像に埋め込まれたテキストが簡潔なテキストによる代替では収まらない場合は、簡潔なテキストによる代替で説明し、併せて長いテキストによる代替で完全なテキストを提供すべきである。

事例

検索ボタンが拡大鏡の画像を使っている。そのテキストによる代替には「拡大鏡」ではなく、「検索」と書かれている
ロープに結び目が作られていく様子を矢印で示して、結び目がどのような結び方になっているかを絵で説明している。そのテキストによる代替は結び方を説明すべきで、その絵が何に見えるかではない。
おもちゃを正面から見た絵がある。そのテキストによる代替はおもちゃの正面から見た様子を説明している。
タイヤの交換方法をアニメーションで示している。簡潔なテキストによる代替はそのアニメーションが何についてであるかを説明している。長いテキストによる代替はタイヤの交換方法を説明している。
TechTron 社のロゴがリスト中のそれぞれの製品の隣にあり、「TechTron」という簡潔なテキストによる代替により製造元を示している。
10 月の売上げを示しているグラフには「10 月の売上表」という簡潔なテキストによる代替がある。併せてそのグラフの全ての情報を提供する長い説明もある。
図案化された文字の「戦争の歴史」という言葉を埋め込んだ画像が見出しにある。その画像に対する代替テキストは「戦争の歴史」である。
棚の上に並んだ本の画像にはその本に関するウェブページへのナビゲーション手段を提供するインタラクティブなエリアがある。「この区画で購入できる本。本を選択するとその本の詳細がわかります。」というテキストによる代替は画像及びインタラクティブな性質を説明している。

参考リソース

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

検証

手順

非テキストコンテンツを削除する、非表示にする、又は隠す。
テキストによる代替で置き換える。
何も情報が失われていないことを確認する (非テキストコンテンツの目的がテキストによる代替によって満たされている)。
非テキストコンテンツがコンテンツを理解する上で重要な単語を含む場合、その単語をテキストによる代替に含めている。

期待される結果

3.の結果が真である。非テキストコンテンツにコンテンツを理解するために必要な単語が含まれている場合は、4.の結果も真であることを確認する。

G95: 非テキストコンテンツの簡単な説明を提供する、簡潔なテキストによる代替を提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する
注記: この達成方法は、達成基準 1.1.1 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.1.1 を理解するを参照すること。

解説

この達成方法の目的は、元の非テキストコンテンツと同じ目的を果たし、同じ情報を提示しようとするとテキストが長くなりすぎてしまう場合、又はテキストのみではこの目的を達成できない場合に用いられる。そのような場合に、非テキストコンテンツを簡単に説明する簡潔なテキストによる代替を提供するために、この達成方法を用いる (長いテキストによる代替は、非テキストコンテンツと同じ目的を果たし、同じ情報を提示するという別の達成方法を併用することで提供される。)。

テキストにどのようなテキストを含めればよいかを決める際は、以下の質問について考えてみるとよい:

なぜこの非テキストコンテンツがここにあるのか？
それはどのような情報を示しているのか？
それはどのような目的を果たすのか？
非テキストコンテンツを使用することができない場合、何という言葉を使って同じ機能及び／又は情報を伝達するか？

事例

10 月の売上げを示している図表には「10 月の売上表」という短いテキストによる代替がある。その図表の全ての情報を提供する長い説明もある。

参考リソース

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

検証

手順

非テキストコンテンツの簡潔な説明を提供している簡単なテキストによる代替があることを確認する。

期待される結果

1.の結果が真である。

G96: 理解させる必要のあるアイテムを感覚的にだけ伝えるのではなく、テキストによる識別情報もあわせて提供する

適用 (対象)

利用者に対して、コンテンツの説明を描画して提示する全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.3 (感覚的な特徴)
- クイックリファレンス 1.3.3 (感覚的な特徴)
- 達成基準 1.3.3 (感覚的な特徴)を理解する

解説

この達成方法の目的は、ウェブページ内のアイテムがコンテンツの中で、形や大きさや音又は位置だけでなく、知覚に依存しない言い回しによっても言及されるようにすることである。例えば、アイテムについて言及する文では、アイテムのラベル又はその機能についてもあわせて説明する。

事例

事例 1

フォームには、入力内容を送信して一連の過程の次の手順に進むために円形のボタンがある。そのボタンにはテキストで「次へ」とラベルが付けられている。説明には、「フォームを送信するには、次へと記された円形のボタンを押して下さい」と示されている。これは、そのボタンを特定するための形とテキスト情報の両方を含んでいる。

事例 2

オンライントレーニングを提供するウェブページの説明には、「希望のオンラインコースへ進むには、右側の『クラス一覧』という見出しがついたリンクのリストを使用して下さい。」と書いてある。この説明は、適切なリンクのリストを見つけること補助するために位置と同様にテキストの手がかりを提供している。

事例 3

以下のレイアウトではボタンを右下隅に配置して位置によってそれを示している。テキストラベルの指示は、位置が意味をなさない線形化バージョンにアクセスする利用者にも、どのボタンを使用するかを明確にしている。

コード例:


              <table>
                <tbody>
                <tr>
                <td colspan="2">Push the lower right [Preview] button.</td>
                <td>
                <span style="background: ButtonFace; color: ButtonText; border: 
                medium outset ButtonShadow; 
                width: 5em; display: block; font-weight: bold; text-align: center;">
                Print</span>
                </td>
                </tr>
                <tr>
                <td>
                <span style="background: ButtonFace; color: ButtonText; border: 
                medium outset ButtonShadow; 
                width: 5em; display: block; font-weight: bold; text-align: center;">
                Cancel</span>
                </td>
                <td>
                <span style="background: ButtonFace; color: ButtonText; border: 
                medium outset ButtonShadow; 
                width: 5em; display: block; font-weight: bold; text-align: center;">
                OK</span>
                </td>
                <td>
                <span style="background: ButtonFace; color: ButtonText; border: 
                medium outset ButtonShadow; 
                width: 5em; display: block; font-weight: bold; text-align: center;">
                Preview</span>
                </td>
                </tr>
                </tbody>
                </table>

参考リソース

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

(今のところ、なし。)

検証

手順

ウェブページ内において、オブジェクトの形、大きさ、又は位置に言及するすべての参照を探し出す。そのような各項目において:

その参照が、形、大きさ、又は相対的な位置についての情報がない場合でも項目を見つけて特定するための追加情報が含まれていることを確認する。

期待される結果

1.の結果が真である。

G97: 略語の初出時、その直前又は直後に元の語を提供する

適用 (対象)

テキストを提供する全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.4 (略語)
- クイックリファレンス 3.1.4 (略語)
- 達成基準 3.1.4 (略語)を理解する

解説

この達成方法の目的は、ウェブページの中で略語が最初に現れたとき、元の語を略語に関連付けることで、略語の元の語を分かるようにすることである。ウェブページで最初の使用箇所を探すことで、すべての略語の元の語を見つけることができる。

英語では、単語、句または名前を、略語、頭文字語、頭字語、又は他の短縮表記によって短くするときは、省略された表記を提供する前に完全な表記を提供する。こうすることで、テキストが読みやすくなり、多くのスタイルガイドでも勧められている。その他の言語では異なる慣習があることもある。

略語の中には、元の語より説明を必要とするものがあることに注意する。そのような略語には、この達成方法は適切ではない。

この達成方法はウェブページで略語の初出時に適用される。複数の資料をひとつのウェブページに結合するとき、それぞれの資料の冒頭で略語の元の語が示される。しかしながら、この場合、元の語を提供するための異なる達成方法を使うことが、より適切であるかもしれない。

事例

事例 1

「国際連合難民高等弁務官事務所 (UNHCR) は、1950 年に難民の保護と支援を提供するために設立された。」

WAI (Web Accessibility Initiative) があることは、W3C のアクセシビリティへの取り組みの証のようなものである。

参考リソース

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

Chicago Manual of Style - Q&A - Abbreviations

検証

手順

コンテンツにある略語それぞれに対して:

作成されたコンポーネントでその略語の最初の使用箇所を探す。
最初の使用箇所の直前又は直後に、略語の元の語があることを確認する。
その元の語が、略語の使用として正しい元の語であることを確認する。

期待される結果

2. 及び 3. の結果が真である。

G98: 送信する前に、利用者が回答を確認及び修正できるようにする

適用 (対象)

試験のデータのように、送信された時点に特定され、ひとたび送信されると変更不可能なデータを利用者から収集するサイト

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、取消不可能なトランザクションが完了する前に、利用者に入力が正しく行われていることを確認するための手段を提供することである。法的義務の生じるもの、金銭的取引、データ変更、試験の回答の送信などにおいては、「取消不可能」なトランザクションが発生することがある。従って、トランザクションが確定してしまうと利用者が間違いを修正する機会がなくなるので、データの送信時に間違いがないことが重要となる。

簡潔な 1 ページのフォームでは、送信前に利用者がフォームの内容を容易に見直すことができる。複数のウェブページにまたがるフォームでは、トランザクションが確定する前に複数のステップで利用者からデータを取得している。トランザクションを確定する以前のステップで入力したデータの全てを利用者が覚えているわけではない。

一つの方法としては、個々のステップの結果をキャッシュし、利用者が思い通りに戻ったり、先に行ったりして入力したデータを見直せるようにすることが考えられる。別の方法としては、トランザクションの最終確定の前に利用者が見直しを行えるようにするために、全てのステップで収集した全てのデータの一覧を提供する。

トランザクションを確定する最終ステップが始まる前に、入力したデータを見直して確認することを促す案内を提供する。そして、利用者が確認を行うとトランザクションが完了するようにする。

事例

オンライン銀行のアプリケーションにおいて、口座間の資金移動を行う際に次のような複数のステップを設けている:
1. 送金元の口座を選択する。
2. 送金先の口座を選択する。
3. 送金する金額を入力する。
送金元と送金先の口座及び送金する金額を示した、送金手続きの一覧が提供される。利用者はトランザクションを完了させるかキャンセルするかのいずれかのボタンを選択することができる。
試験のアプリケーションにおいて、複数のページにわたって問題が掲載されている。利用者はいつでも、前に答えを入力し終えた場所の答案を見直したり変更したりできる。さらに最終ページには、試験の答案を送信する、又は見直すためのボタンが提供されている。

検証

手順

試験のアプリケーションの場合、又は金融、法律上のトランザクションが発生し、複数のステップで利用者からデータを収集する場合:

利用者に入力内容を確認するように促している。
利用者のデータが複数のステップで収集される場合、利用者が前のステップに戻ってデータを見直し及び変更できる。
トランザクションが確定する前に、利用者が入力した全てのデータの一覧が提供され、必要に応じて間違いを修正する方法が提供されているかどうかを判断する。

期待される結果

2. 又は 3. のいずれかの結果が真である。

G99: 削除した情報を復元する機能を提供する

適用 (対象)

利用者の操作によって削除されるコンテンツ

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、ウェブアプリケーションで情報を削除できる場合、利用者によって誤って削除された情報を復元する手段をサーバーが提供することである。一つの方法として、削除をするものにマークを付けるだけにする、又は (ゴミ箱のように) 情報を保持する領域に移動させるなど、データの削除に時間差を設けて、実際に削除するまでにしばらくの間待機することが考えられる。この間、利用者はデータを復元したり、一時的な保持領域から取り出したりすることができる。他には、wiki 及びソースコントロールアプリケーションで編集履歴が保持されているように、利用者が必要なときにデータを復元できるように全ての削除操作を記録しておく方法がある。トランザクションの修正が必要となる情報は保存し、利用者が取り出し可能なようにしておくべきである。

事例

ウェブアプリケーションで、利用者がフォルダを作成してデータをその中に保存しておくことができる。各フォルダとデータ項目には、動作のマークを付けるチェックボックスと、移動するボタンと削除するボタンの二つのボタンが付いている。利用者が削除ボタンを間違って選択した場合は、多量のデータが失われてしまうかもしれない。そのアプリケーションは、利用者にデータが削除されたことをすぐに表示するが、実際の削除は一週間後に設定されている。一週間の間、利用者は「削除されたアイテム」フォルダを開き、実際に削除されるのを待っているフォルダやデータの復元を要求することができる。

検証

手順

コンテンツを削除する機能を特定する。
コンテンツを削除して、復元してみる。
削除された情報が復元できるかどうかを確認する。

期待される結果

3. の結果が真である。

G100: 非テキストコンテンツの一般に認められた名前 (name) 又は説明的な名前となる簡潔なテキストによる代替を提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

解説

この達成方法の目的は、非テキストコンテンツが特定の感覚的体験を提供することを意図している場合においても、利用者が非テキストコンテンツを特定できるようにすることである。例えば、耳が聞こえない利用者は、たとえ聞くことができなくとも、音声ファイルがどのようなものか知りたいと思うだろう。同じように、全盲の利用者も、たとえ見ることができなくとも視覚的な映像の題材がどのようなものか知りたいと思うだろう。

事例

事例 1

モナリザの絵には「モナリザ。レオナルドダビンチ作」という代替テキストがある。
音声ファイルには「テルミンを演奏している 5 人の小学生」という代替テキストがある。
有名なモダンアートの作品には「赤、青、及び黄色。ピエト　モンドリアン作」という表題が付けられている。

参考リソース

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

G68: ライブの音声のみのコンテンツ及びライブの映像のみのコンテンツの目的を説明するために、簡潔なテキストによる代替を提供する

検証

手順

簡潔なテキストによる代替が内容が分かる名前を提供しているかどうかを確認する。
簡潔なテキストによる代替がコンテンツ制作者又は他者によって以前に非テキストコンテンツに付けられている名前を提供していることを確認する。

期待される結果

1. 又は 2. の結果が真である。

G101: 一般的ではない、又は限定された用法で用いられている単語又は語句の定義を提供する

適用 (対象)

テキストを含むあらゆるウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.3 (一般的ではない用語)
- クイックリファレンス 3.1.3 (一般的ではない用語)
- 達成基準 3.1.3 (一般的ではない用語)を理解する

解説

この達成方法の目的は、一般的ではない、又は限定された用途で用いられているあらゆる単語の定義を提供することである。

単語が、一般的ではない、又は限定された用途で用いられているのは、次のような場合である:

辞書にはその単語の定義がいくつかあるが、コンテンツを理解するためには一つの特定の定義が用いらなければならない。
コンテンツを理解するために特定の定義が用いられている、又辞書には、それらの定義はまれな、廃れた、旧式のと書かれている。
コンテンツ制作者が、コンテンツを理解するために用いられる新しい定義を作り出す。

この達成方法は、業界用語、すなわち、特有の専門又は技術分野で用いられる専門用語に対して定義を提供するためにも用いられる。分野外の人には理解できないが、その分野の人には理解できる。

この達成方法は慣用表現を定義するためにも用いられる。例えば、同じ言語を話す人でも、特定の地域に住んでいる場合、その地域の人には理解されるが、同じ言語を話す他の地域からの人には理解されない慣用表現を用いるかもしれない。

事例

事例 1: 限定された用途で用いられている専門用語

「技術」という単語は、原始人が使った石器から携帯電話のような現代のデジタル機器までの全てを含め広く用いられている。しかし、WCAG 2.0 では、「技術」という単語はより限定された用途で用いられている: それは、ユーザエージェントにより描画、再生、又は実行されるように指示をコード化するためのメカニズムを意味しており、ウェブコンテンツを生成及び提供する際に用いられるマークアップ言語、データフォーマット、及びプログラム言語を含んでいる。

事例 2: 一般的にはもう使われていない定義が用いられている用語

「エーテル」という用語は、宇宙空間に満たされた物質として定義されている: 「彼はエーテルを介して音が伝わると信じていた。」

事例 3: 業界用語

「ドライバー」という用語は、プリンターでは特定の指示をするソフトウェアとして定義されている: 「あなたのプリンタのドライバーをアップデートする必要があるかもしれない。」

事例 4: 固有表現

例えば、「警察署で、ジョーは首相を誘拐するたくらみについて口をすべらした。」のように、「秘密を漏らす」の意味で「口をすべらす」と言う人がいる。

事例 5: 日本語の慣用表現

この事例は、日本語の慣用表現の定義を提供するために括弧を使用する。日本語の語句では、「さじを投げる。」と書かれている。これは、彼のできることが何もなく、最終的にあきらめたことを意味している。

さじを投げる (どうすることもできなくなり、あきらめること)。

事例 6: 英語で馴染みのない外来語

利用者は、他の言語からの馴染みのない外来語を理解できないかもしれない: 「我々はすぐに (すばやく) 街を離れる必要がある。」

事例 7: 日本語で馴染みのない外来語

日本語では、外来語に対してカタカナが用いられる。単語が利用者にとって馴染みがない場合、利用者が理解できるように意味又は翻訳を提供する。

アクセシビリティ (高齢者・障害者を含む全ての人が利用できること) は、ウェブサイトに不可欠である。

レイアウトテーブルと CSS の併用をハイブリッド (複合型) という。

参考リソース

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

検証

手順

一般的でない、又は限定された用途で用いられる個々の単語又は語句に対して:

単語又は語句に対して定義が提供されていることを確認する。

期待される結果

1.の結果が真である。

G102: 略語の元の語又は説明を提供する

適用 (対象)

テキストを提供する全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.4 (略語)
- クイックリファレンス 3.1.4 (略語)
- 達成基準 3.1.4 (略語)を理解する

解説

この達成方法の目的は、略語を理解するために必要な情報を提供することである。

略語とは、単語、句、又は名前の短縮表記である。ほとんどの略語では、元の単語、句、又は名前を提供すれば十分である。

略語には、外国語に由来した単語又は句を表したものがある。例えば、英語で一般的に使用される略語の多くは、以下の事例一覧表で示すように、ラテン語の語句に由来する。ここでは、元の語は背景情報としてのみ提供する。こういった部類の略語では、語の説明を提供するほうが元の表記より役立つので、元の表記の代わりに略語の説明を提供する。

略語	ラテン語の表記	語の説明
a.m.	ante meridiem	正午より前。午前。
p.m.	post meridiem	正午より後。午後。
e.g.	exempli gratia	例えば。
cf	confer/conferatur	参照。

略語が元の表記を必要としない場合 (例えば、当該組織が元の表記を廃止している、又は略語がその言語の一部になっている)、説明を提供する、又は適切なら、説明を必要としない単語として略語を見なす。

事例

事例 1: ADA

略語の中には、複数の意味があり、文脈に依存するものがある。例えば、ADA はある文脈では「American Dental Association」を意味し、別の文脈では「Americans with Disabilities Act」を意味する。文脈に適切な元の語を提供しなければならない。

事例 2: 英語の略語でラテン語由来の句に対するもの

次の文章中において、「e.g.」には「例えば」という説明が提供される: チーム制のスポーツ (e.g. バスケットボール又はフットボール) に参加する学生は、チームの練習時間に彼らのスケジュールを合わせなければならない。

事例 3: ABS

いくつかの言語 (英語及びオランダ語を含む) では、頭字語 ABS (Antiblockiersystem: アンチロックブレーキ) をドイツ語から借用している。元の表記ではなく、語の説明 (anti-lock brakes) が提供されている。

事例 4: 元の語のない頭字語

もはや元の語を持たない頭文字語の例

SIL は、Summer Institute of Linguistics を意味していたが、現在はそれ自体が名前である。SIL の歴史を参照。
IMS は、Instructional Management Systems を意味していたが、現在はそれ自体が名前である。

こういった部類の例では、組織がどのようなものか、又は何をするのかについての短い説明で十分である。

事例 5: かつての略語であったが、その言語の一部となった句

「夜に」を意味するオランダの断片「's nachts」は、元々は「des nachts」の略語である。現在のオランダ語では、「des」という単語はもうめったに使用されず、古風であるとされる。元の表記を提供すると混乱する。「's nachts」においては、元の語は提供しない。

「o'clock」という英語の句は、元々は「of the clock」の略語であった。「o'clock」は英語の一部になっており、元の語を提供する必要はない。

参考リソース

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

検証

手順

コンテンツの略語それぞれについて:

略語に元の語が無い場合は、説明を提供されている。
略語の元の語がコンテンツとは異なる言語の場合は、説明が提供されている。
それ以外の場合は、元の語が提供されている。

期待される結果

上記の全ての結果が真である。

G103: アイデア、イベント及びプロセスを説明するのに役立つ、視覚的なイラスト、写真及びシンボルを提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.5 (読解レベル)
- クイックリファレンス 3.1.5 (読解レベル)
- 達成基準 3.1.5 (読解レベル)を理解する

解説

この達成方法の目的は、概念やプロセスが記述された難しいテキストについて、読字障害者の理解を助ける視覚的な図画を提供することである。図画はそのテキストに追加で提供する。

単語や文章の読解が難しいという障害のある利用者は、難解なテキストを読んだり理解するのに苦労することが多い。図表、略図、アニメーション、写真、統合図及び他の視覚的な素材は、これらの利用者に役立つことが多い。例えば:

図表やグラフは、複雑なデータの理解に役立つ。
略図、フローチャート、ビデオ、アニメーションは、プロセスの理解に役立つ。
概念図及び他の統合図は、アイデア同士の関係を理解するのに役立つ。
写真、デッサン、ビデオは、自然や歴史上の出来事や対象の理解に役立つ。

事例

事例 1: 会社の年次報告書

ある年次報告書では、会社の前年度の業績に影響を与えたさまざまな要因を説明している。これらの要因がどのように作用し合っているかを示す図表やグラフを報告書に含めてある。図表やグラフそれぞれには、達成基準 1.1.1 が要求するテキストによる代替を提供し、キャプションには番号を振ってある (例えば「図 7」)。図表やグラフが参照できるように、これらの番号をテキストの中でも用いている。

事例 2: 技術文書内のスクリーンショット

ある製品のオンライン文書には、段階的な取り扱い説明を含めてある。各段階は、画面の視覚表現であるスクリーンショットで示している。各スクリーンショットには、達成基準 1.1.1 が要求するテキストによる代替を提供している。

事例 3: 複雑な自然現象の図画

あるウェブサイトでは、2004 年の津波について説明している。津波がインド洋の周辺地域にどのような影響を与えたかの解説や、荒廃の様子を写した写真を含めている。各写真には、達成基準 1.1.1 が要求するテキストによる代替を指定してある。さらに、津波の間、水面下では何が起きているか説明し、津波の発生と海に広がる様子をアニメーションとして付けてある。アニメーションには、達成基準 1.1.1 が要求するテキストによる代替を提供している。

参考リソース

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

Tufte, Edward. Envisioning information. Cheshire, Conn.: Graphics Press. 1990.
Tufte, Edward. The visual display of quantitative information. Cheshire, Conn.: Graphics Press. 1983.
Tufte, Edward. Visual explanations: images and quantities, evidence and narrative. Cheshire, Conn.: 1997.

(今のところ、なし。)

検証

手順

コンテンツの利用にあたって理解が不可欠なアイデアやプロセスを説明しているテキストを特定する。
コンテンツの中で、又は、コンテンツ内のリンクを通じて、視覚的な図画が利用できることを確認する。
視覚的な図画が、テキストで説明している概念又はプロセスを表していることを確認する。

期待される結果

2. 及び 3. の結果が真である。

G105: 利用者が再認証した後に利用できるようにデータを保存する

適用 (対象)

データを送信するのに、利用者認証を求め制限時間のあるウェブページ

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.5 (再認証)
- クイックリファレンス 2.2.5 (再認証)
- 達成基準 2.2.5 (再認証)を理解する

解説

利用者に認証を求めるウェブサーバーは、一定時間、利用者の操作がない場合、セッションを終了することがよくある。利用者が素早くデータを入力できず、送信前にセッションが時間切れになってしまった場合、プロセスの続行前にサーバーから再認証が求められるだろう。この場合、サーバーはキャッシュの中にデータを一時的に保存しておき、その後、利用者がログインし、再認証したら、データがキャッシュから利用可能になり、まるでセッションの時間切れがなかったかのようにフォームを処理する。サーバーはキャッシュを無期限には保持できず、利用者の単一セッション中の再認証後まで保持できる長さは、例えば 1 日ぐらいでしかない。

事例

あるフォーラムに利用者がログインし、回答を送信しようとしている。回答が書き終わる時間は、サーバーから許可されている不操作セッション時間よりも長いとする。利用者は回答を送信したが、セッションの時間切れが通知され、回答の再送信のためにログインするよう促された。利用者の回答はサーバーに保存されており、ログインが成功すれば通常通り回答が処理される。ログインが成功しなければ、回答は破棄される。
セキュリティが保護されたエリアに利用者がログインし、フォームに入力している。セキュリティ上の理由のため、セッションが時間切れになった。フォームデータはサーバーに保存され、利用者には時間切れが通知され、再ログインが促される。利用者が正しくログインできれば、全てのデータが以前に入力された状態でフォームが表示される。ログインが成功しなければ、フォームデータは破棄される。

G181: 利用者のデータを、再認証したページで非表示データ又は暗号化されたデータとしてエンコーディングする

検証

手順

データの送信にあたって利用者にログインを求めるサイトについて:

ログインし、制限時間のある操作を始める。
セッションを時間切れにさせる。
データを送信する。
再認証する。
元のデータ及び再認証後の変更内容を含めた、データの損失なしに、プロセスが継続可能して完了できることを確認する。

期待される結果

5. の結果が真である。

G107: コンテキストの変化に対するトリガーとして、"focus" ではなく、"activate" を使用する

適用 (対象)

全てのウェブコンテンツ技術に適用する。

これは、次の達成基準に関連する達成方法である:

達成基準 3.2.1 (フォーカス時)
- クイックリファレンス 3.2.1 (フォーカス時)
- 達成基準 3.2.1 (フォーカス時)を理解する

解説

この達成方法の目的は、利用者が予測できるように、機能を実行する手法を提供することである。認知障害の利用者及びスクリーンリーダーや画面拡大ソフトを使用している利用者は、フォームが自動的に送信されたり、コンテキストの変化を引き起こす機能が実行されたりするなど、予期せぬイベントによって混乱することがある。

この達成方法を用いることにより、状況の全ての変化は利用者の特定の動作によってのみ引き起こされる。さらに、その動作は通常状況の変化を引き起こすものであり、例えばリンクをクリックしたり送信ボタンを押したりすることが挙げられる。単にフォーカスをある要素に移すだけの動作は、コンテキストの変化を引き起こすものではない。

事例

事例 1

ページが新しいウィンドウをポップアップ表示するのは、利用者がフォーカスを移動させたときではなく、ボタンをクリックした (又はスペースキーを使った) ときのみとする。
利用者が完了ボタンにタブで移動したときに自動的に次の画面を表示するのではなく、送信ボタンを使用したときに次のデータ入力画面に移動するようにする。

参考リソース

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

(今のところ、なし。)

検証

手順

キーボードを利用して、全てのコンテンツへフォーカスを移動する。
どの構成要素がフォーカスを受け取ったときにも、コンテキストの変化が発生しないことを確認する。

期待される結果

2.の結果が真である。

G108: 名前 (name) 及び役割 (role) を公開し、利用者が設定可能なプロパティを直接設定可能にして、変化の通知を提供するために、マークアップを用いる

適用 (対象)

名前及び役割を明示すること、利用者が設定可能なプロパティを直接設定可能にすること、及び変化を通知することが可能なマークアップウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- クイックリファレンス 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- 達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )を理解する

解説

この達成方法の目的は、支援技術がウェブコンテンツを理解できるようにすることである。そうすることで、代替のユーザインタフェースを通して利用者に等価の情報を伝えることができ、また支援技術を通してコントロールを操作することができるようになる。

この達成方法は、これらのプロパティを支援技術に明示するために、標準で、文書化され、かつサポートされた機能を使用することを前提にしている。それは標準的なブラウザにおいてこれら標準的なコントロールは仕様にそっているからである。

HTML に対してはこれらの条件が当てはまる。他のウェブコンテンツ技術に対しても当てはまるかもしれない。

構成要素がアクセシビリティをサポートしている時でさえ、コンテンツ制作者によって提供される情報は必要不可欠である。例えば、コントロールは名前 (name) を提供する能力を持っているかもしれないが、コンテンツ制作者はそれでも名前を提供しなければならない。また一方、それは固定の役割 (role) のある標準的な構成要素であるため、役割 (role) の属性はすでに提供されているかもしれない。

事例

事例 1

HTML 又は XHTML で書かれたウェブページは標準的なフォームコントロールを使用し、タイトル属性を使用してフォームコントロールを特定している。ユーザエージェントは、これらコントロールに関する情報を、名前を含めて生成する。そして、DOM とプラットフォーム特有のアクセシビリティ API を通して支援技術が利用可能となる。

参考リソース

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

検証

手順

マークアップを視覚的に確認する、又はツールを使用する。
それぞれのユーザインタフェースコンポーネントに対して、名前 (name) 及び役割 (role) を判断できるように適切なマークアップが使用されていることを確認する。
利用者の入力を受け取るユーザインタフェースコンポーネントが全て支援技術から操作できるように適切なマークアップが使用されていることを確認する。

期待される結果

各ユーザインタフェースコンポーネントにおいて、2. と 3. の両方の結果が真である。

G110: クライアントサイドの瞬間的なリダイレクトを使用する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 3.2.5 (要求による変化)
- クイックリファレンス 3.2.5 (要求による変化)
- 達成基準 3.2.5 (要求による変化)を理解する

解説

この達成方法の目的は、クライアントサイドで利用可能なリダイレクトを、利用者を混乱させることなく用いることである。リダイレクトはサーバーサイドで実装するほうが望ましい (SVR1: クライアントサイドではなく、サーバーサイドで自動リダイレクトを実装する (SERVER) を参照)。なぜなら、サーバーサイドのリダイレクトでは、新たな URI にあるコンテンツをサーバーが送信する前にコンテンツが表示されてしまうことがないからである。しかし、コンテンツ制作者がサーバーサイド技術を管理しているとは限らず、このような場合にはクライアントサイドのリダイレクトを用いることができる。コンテンツを異なる URI から取得すべきことをユーザエージェントに指示するコードを埋め込むことで、クライアントサイドのリダイレクトが実装できる。リダイレクト元のページには、リダイレクトに関する情報のみを含めておくことが重要である。

事例

事例 1: HTML: meta 要素の refresh で、URI を指定し、タイムアウトを指定しない方法

HTML 4.x と XHTML 1.x では、mata 要素を用いることでクライアントサイドのリダイレクトが実装できる。H76: クライアントサイドで瞬間的にリダイレクトするために、meta 要素の refresh を使用する (HTML) を参照のこと。

訳注: HTML 4.x 及び XHTML 1.x は Superseded Recommendation としてマークされ、廃止された仕様である。

参考リソース

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

検証

手順

他のウェブページへの各リンク又はプログラム参照を見つける。
各リンク又はプログラム参照について、参照先のウェブページにクライアントサイドのリダイレクトを引き起こすコード (meta 要素やスクリプトなど) が含まれているかどうかを確認する。
クライアントサイドのリダイレクトが生じるリンク又はプログラム参照について、リダイレクトが時間制限も遅延もなく実装され、そのページにはリダイレクトに関する情報のみが含まれているかどうかを確認する。

期待される結果

2. の結果が偽、又は 3. の結果が真である。

G111: 色とパターンを併用する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.1 (色の使用)
- クイックリファレンス 1.4.1 (色の使用)
- 達成基準 1.4.1 (色の使用)を理解する

解説

この達成方法の目的は、非テキストコンテンツの中で情報を伝達するために色の違いを用いている場合に、色に依存することなく同じ情報を伝達するためにパターン (模様) を併用することである。

事例

事例 1

不動産会社のサイトに、米国のいくつかの地域における平均住宅価格の棒グラフがある。それぞれの地域を表す棒は、異なる色及び異なるパターンで表示されている。凡例は、それぞれの棒が識別できるように、同じ色とパターンが使用されている。

事例 2

交通システムのオンライン地図には路線が色分けされている。それぞれの路線上の停車場は菱形、正方形又は円など、区別しやすいアイコンになっており、路線を区別しやすくしている。

事例 3

プロセスを完了するまでの一連の反復手順を示すフローチャートがある。フローチャートでは、条件を満たした場合に、プロセスの次のステップを指す、緑色の背景に破線の矢印が使用される。条件を満たさない場合に、プロセスの次のステップを指す、赤の背景に点線の矢印が使用される。

事例 4

コンテンツにはインタラクティブなゲームがある。4 人分のゲームのコマは、色とパターンの両方を使っておりそれぞれ識別できるようになっている。

参考リソース

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

G14: 色の違いで伝えている情報をテキストでも入手可能にする

検証

手順

情報を伝達するために色の違いを用いているウェブページ内の各画像に対して:

色を用いて伝達されている情報の全てに、色に依存しないパターンも併用している伝達されることを確認する。

期待される結果

1.の結果が真である。

G112: インラインの定義を使用する

適用 (対象)

テキストを含むあらゆるウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.3 (一般的ではない用語)
- クイックリファレンス 3.1.3 (一般的ではない用語)
- 達成基準 3.1.3 (一般的ではない用語)を理解する

解説

この達成方法の目的は、一般的ではない、又は限定された用途で用いられているあらゆる用語に対して文脈の中で定義を提供することである。定義は、単語が使われている直前又は直後のいずれかに、テキストで提供される。定義は、定義される単語として同じ文章の中、又は異なる文章の中に記載されることが望ましい。

事例

事例 1: エーテル

彼はエーテルを介して音が伝わると信じていた。それは、宇宙空間に満たされている物質と考えられていた。

事例 2: ドライバー

プリンタのドライバーをアップデートする必要があるかもしれない (ドライバーはプリンタの特定の指示を含んでいるソフトウェアである)。

事例 3: W3C のキーワード

定義: この基準で、「しなければならない (must)」、「してはならない (must not)」、「しなければならない (required)」、「しなければならない (shall)」、「してはならない (shall not)」、「することが望ましい (should)」、「しないほうがよい (should not)」、「することが望ましい (recommended)」、「してもよい (may)」、及び「してもよい (optional)」のキーワードは、RFC 2119 に記載されている解釈による。

事例 4: 文脈中で定義された日本語の慣用句の表現

この事例では、日本語における慣用句表現の定義を提供するために括弧を使用する。日本語の語句には「彼はさじを投げる。」と書かれている。これは、彼が何もできず、最終的にあきらめたことを意味している。

さじを投げる (どうすることもできなくなり、あきらめること)。

参考リソース

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

検証

手順

一般的ではない、又は限定された用途で使われる個々の単語又は語句に対して:

単語の初出箇所の前か後ろのいずれかで、単語がテキストで定義されていることを確認する。

期待される結果

1.の結果が真である。

G115: 構造をマークアップするために、セマンティックな要素を使用する

適用 (対象)

HTML 4.01 及び XHTML 1.x を含むマークアップ言語

訳注: HTML 4.01 及び XHTML 1.x は Superseded Recommendation としてマークされ、廃止された仕様である。

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

解説

この達成方法の目的は、適切なセマンティックな要素を用いてウェブコンテンツの構造をマークアップすることである。つまり、要素を、視覚的な見えかたではなく、その意味に基づいて用いることである。

適切なセマンティックな要素を用いることは、ユーザエージェントが構造を確実に利用できるようにする。この中には、コンテンツの意味を理解する上でさまざまな構成要素が持っている役割 (role) を明示することも含まれる。段落、見出し、強調されたテキスト、テーブルなどのコンテンツの構成要素の性質は、このようにして示すことができる。場合によっては、見出しと小見出し、テーブルとセルといった複数の構成要素間の関係も示されるべきである。そうすることで、ユーザエージェントは、例えば、異なる種類の構造に対して異なる視覚的提示にしたり、聴覚的提示において異なる声又は声の高さを用いたりすることによって、利用者に構造を知覚可能にすることができる。

例えば、HTML においては、em、abbr 及び cite といった語句レベルの要素は、それぞれ、強調させるため、略語及び引用であることを示すためにテキストをマークすることで、文の中でセマンティックな情報を付加する。数学における構造と提示の重要な区別を保つために設計されたマークアップ言語である MathML には、数学的な概念を表すために用いられる複雑な記号のための特別な「提示」のマークアップも、数学的な概念自体のための「コンテンツ」 (セマンティック) マークアップも含まれている。

事例

事例 1

段落には別のページへのハイパーリンクがある。ハイパーリンクは a 要素を用いてマークアップされている。

コード例:


              <p>Do you want to try our new tool yourself? A free 
                demonstration version is available in our 
                <a href="download.html">download section</a></p>

事例 2

結婚の歴史についてのページには、ジェーンオースティンの小説「Pride and Prejudice」からの引用が事例として用いられている。本への参照は、cite 要素を用いてマークアップされ、引用部分自体は blockquote 要素を用いてマークアップされている。

コード例:


              <p>Marriage was considered a logical step for a bachelor, 
                as can be seen in the first chapter of the novel 
                <cite>Pride and Prejudice</cite>:</p>
                <blockquote>
                <p>It is a truth universally acknowledged, that a single man in
                possession of a good fortune, must be in want of a wife.</p>
                <p>However little known the feelings or views of such a man may
                be on his first entering a neighbourhood, this truth is so well
                fixed in the minds of the surrounding families, that he is considered
                the rightful property of some one or other of their daughters.</p>
                </blockquote>

訳注: WAIC では G115-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: G115-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 3

車の取扱説明書にエンジンのかけ方の説明がある。説明書きには、ギアがニュートラルになっていることを確かめるようにとの警告がある。筆者は、その警告は非常に重要で強調されるべきであると考えていたため、警告は strong 要素を用いてマークアップされている。

コード例:


              <h1>How to start the engine</h1>
                <p>Before starting the engine, <strong>make sure the gear 
                is in neutral</strong>. Next, turn the key in the ignition. 
                The engine should start.</p>

訳注: WAIC では G115-3 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: G115-3 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 4

この事例では、テキストを強調するために em 及び strong 要素をどのように用いたらよいかを示している。

訳注: MDN の strong 要素で示されているように、古い HTML では strong 要素を単により強い強調としていたが、現在の HTML では strong 要素を重要性を表すものと定義している。

コード例:


              <p>What she <em>really</em> meant to say was, 
                "This is not ok, it is <strong>excellent</strong>!"</p>

訳注: WAIC では G115-4 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: G115-4 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 5: 強調及び背景色を用いて重要な情報を視覚的かつセマンティックに特定する。

コード例:


              <style type="text/css">
                .vocab {
                background-color:cyan;
                font-style:normal;
                }
                </style>
                ...
                <p>New vocabulary words are emphasized and highlighted 
                with a cyan background</p>
                <p>The <em class="vocab">scathing</em> review of the play 
                seemed a bit too harsh... </p>

訳注: WAIC では G115-5 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: G115-5 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

参考リソース

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

HTML 4.01 specification
HTML 4.01 specification, using phrase elements
Mathematical Markup Language (MathML) Version 3.0 2nd Edition
Jeffrey Zeldman's book "Designing with Web standards"
Web Design Group's article "Document style: Use the right tag for the job"

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記は、HTML 5.2: 4.5. Text-level semantics を代わりに参照できる。

検証

手順

セマンティックな機能を有するコンテンツの部分があるかどうかを確認する。
セマンティックな機能がある部分について、対応するセマンティックなマークアップがウェブコンテンツ技術に存在する場合、コンテンツがそのセマンティックなマークアップを用いてマークアップされていることを確認する。

期待される結果

2 の結果が真である。

G117: テキストの提示のバリエーションによって伝えている情報を伝達するために、テキストを使用する

適用 (対象)

テキストの視覚的提示のバリエーションをサポートするウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

解説

この達成方法の目的は、テキストの書式のバリエーションを通じて伝達される情報が同様にテキストで伝達するように保証することである。情報の伝達のためにテキストの視覚的な外観が変化する場合、テキストでその情報を明示する。フォントの書体、フォントサイズ、下線、取り消し線及びその他の様々なテキスト属性を変えることによって、視覚的な外観にバリエーションをもたせることができる。このようなバリエーションが何らかの情報を伝達している場合、その情報はコンテンツのどこか他の場所でテキストによっても入手可能である必要がある。ドキュメント内に補足説明を加えること、又はテキストの提示のバリエーションを用いている箇所にインラインで説明を加えることによって、その情報を伝達することができる。

事例

事例 1: 新しいコンテンツをボールドの文字とテキストで示す

以下の例はアクセシビリティ標準のリストである。WCAG 2.0 は新しいため、ボールドで表示されている。単に提示で情報を伝えるのを避けるため、「(new)」という単語も後ろにつけている。

訳注: MDN の strong 要素で示されているように、単に字を太くする目的であれば、b 要素を使用するのが適切である。

コード例:


          <h2>Web Accessibility Guidelines</h2>
            <ul>
            <li><strong>WCAG 2.0 (New)</strong></li>
            <li>WCAG 1.0</li>
            <li>Section 508</li>
            <li>JIS X 8341-3</li>
            ...
            </ul>

事例 2: フォントのバリエーション及び明確な提示

オンライン上のある文書が、ドラフトを更新しながら版を重ねている。挿入部分には下線を引き、削除部分は取り消し線を引いている。ドラフトの最後に、「変更履歴」があり、それぞれのドラフトに対する変更箇所の全てをリスト化している。

事例 3: テキスト内のどの単語に異なるフォントが当てられているか知るための代替手段を提供する

あるオンラインテストでは、学生に対し、長い文章の短い要約を書くことを求めている。その要約には、原文にあるいくつかの単語を含めなければならない。原文では、要約に用いなければならない単語やフレーズが、他と異なるフォントで表示されている。独立したセクションにおいても、要約で用いなければならない単語やフレーズすべてがリスト化されてる。

参考リソース

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

検証

手順

テキストの提示のバリエーションが情報を伝えるために使用される項目を見つける。
これらの項目について、視覚的に伝達される情報がテキストにも明示的に記載されているかどうかを確認する。

期待される結果

2 の結果が真である。

G120: 単語の直後に発音 (読み) を提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.6 (発音)
- クイックリファレンス 3.1.6 (発音)
- 達成基準 3.1.6 (発音)を理解する

解説

この達成方法の目的は、単語がウェブページの中で少なくとも最初に現れたとき、後ろに読みを提供することにより単語の読み方が分かるようにすることである。

同じつづりで異なった読みの単語がウェブページにあるときは、その単語が現れるごとに読みが提供されない場合、この達成方法は読みの提供として適切なものとはならない。

この達成方法はウェブページで略語の初出時に適用される。複数の資料をひとつのウェブページに結合するとき、それぞれの資料の冒頭で略語の元の語を示す。しかしながら、この場合、元の語を提供するための異なる達成方法を用いる方が、より適切であるかもしれない。

事例

事例 1: Example 1

以下の日本語のテキストの例では、漢字の読みを与える情報は、テキストの直後の丸括弧の中に描画される。

コード例:

<p> 慶應大学 (けいおうだいがく) </p>

参考リソース

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

検証

手順

読みを必要とする単語それぞれに:

ウェブページのなかで、その単語の最初の使用箇所を探す。
最初の使用箇所の直後にその単語の読みがあることを確認する。

期待される結果

2.の結果が真である。

G121: 発音 (読み) にリンクする

適用 (対象)

リンクを含む全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.6 (発音)
- クイックリファレンス 3.1.6 (発音)
- 達成基準 3.1.6 (発音)を理解する

解説

この達成方法の目的は、単語の発音に関する情報を同じウェブページ又は異なるウェブページ上で提供し、対象となる単語から発音の情報へリンクすることにより、その単語の発音を入手可能にすることである。

事例

事例 1

単語がその発音情報を含む辞書にリンクされている。

事例 2

単語がその発音を含む音声ファイルにリンクされている。

事例 3

単語が発音辞書 (発音音声を提供することを目的とした辞書) にリンクされている。

事例 4

単語がその発音の International Phonetic Alphabet (IPA) 表現にリンクされている。

事例 5

単語がその発音を曖昧性のないように書き下したスペリングにリンクされている。

参考リソース

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

検証

手順

発音情報を必要とする単語の全てについて:

少なくともその項目の最初の箇所がリンクであることを確認する。
各リンクが項目の発音に関する情報にナビゲートすることを確認する。

期待される結果

上記全ての結果が真である。

G123: 繰り返しているコンテンツのブロックの先頭に、そのブロックの末尾へのリンクを追加する

適用 (対象)

リンクを実装できる全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.1 (ブロックスキップ)
- クイックリファレンス 2.4.1 (ブロックスキップ)
- 達成基準 2.4.1 (ブロックスキップ)を理解する

解説

この達成方法の目的は、ブロックの終わりまで飛び越えることで、構成要素のブロックを回避するメカニズムを提供することである。ブロックの最初のリンク又はブロックの直前にあるリンクによって、フォーカスをそのブロックの直後にあるコンテンツに遷移させる。リンクを選択することでキーボードフォーカスはブロックを飛ばして進んでいく。複数のブロックを飛び越える場合は、利用者はこれらのリンクを使ってブロックを一つずつスキップしていく。

事例

事例 1: ナビゲーションリンクをスキップする

ある組織のウェブサイトのページには、サイトの主なセクション、サイトマップ、組織についての情報、及び組織との連絡方法へのリンクを含むナビゲーションバー又はメインメニューがある。このエリアの最初のリンクは「ナビゲーションリンクをスキップする」で、利用者はそのリンクを選択してこれらのリンクをスキップする。

事例 2: 本の索引

本の中に何ページかのセットになって区分されている索引がある。索引のそれぞれのページの冒頭にあるコンテンツの中には、アルファベットのそれぞれの文字に対するリンクがあり、その文字で始まる記載内容の索引にリンクしている。そのセットの中の最初のリンクは「リンクをスキップして索引へ」である。利用者は、このリンクを選択して他のリンクをスキップする。

事例 3: 複数のリンクの集合

ウェブサイト内の全てのページにはサイトマップ、組織に関する情報、及び組織との連絡方法へのリンクが含まれているセクションがある。サイトにある各セクションの全てのページには、同様にその下位の区分へのリンクの集合がある。1 番目のブロックの最初のリンクは「ナビゲーションリンクをスキップ」で、最初のリンクの集合をスキップする。2 番目のブロックの最初のリンクは「セクションのリンクをスキップ」で、そのサブセクションのリンクをスキップする。

事例 4: ナビゲーションリンクのブロックが複数ある HTML ページ

この事例では、各セクションの先頭に見出し要素を使用する方法 (H69) と、各セクションの最後にスキップするリンクを使用する両方を示している。これにより、ユーザエージェントの能力に応じて、キーボードナビゲーション又は見出しナビゲーションを用いて、繰り返されるコンテンツのブロックをスキップすることができる。コンテンツのいくつかのセクションは、Internet Explorer の制限を回避するために div 要素で包まれていることに注意すること (コンテンツのブロックをスキップするための HTML リンクを作成するユーザエージェントノートを参照 (リンク追加予定))。

訳注: コード例の <div class="iekbfix"> については、hasLayout と呼ばれる、Internet Explorer (IE) 独自のプロパティを利用した、IE6 上でのキーボード操作に対するハックである (なお、IE6 は既にサポートが終了しているブラウザである)。IE11 及びモダンブラウザでは、このようなハックが必要ないことに注意されたい。

コード例:


              <p><a href="#content">Content title</a></p>
                <h2>Main Navigation</h2>
                <ul>
                <li><a href="#subnav">Sub Navigation</a></li>
                <li><a href="/a/">Link A</a></li>
                <li><a href="/b/">Link B</a></li>
                <li><a href="/c/">Link C</a></li>
                ...
                <li><a href="/j/">Link J</a></li>
                </ul>
                <div class="iekbfix">
                <h2 id="subnav">Sub Navigation</h2>
                <ul>
                <li><a href="#ultranav">Ultra Sub Navigation</a></li>
                <li><a href="/suba/">Sub A</a></li>
                <li><a href="/subb/">Sub B</a></li>
                <li><a href="/subc/">Sub C</a></li>
                ...
                <li><a href="/subj/">Sub J</a></li>
                </ul>
                </div>
                <div class="iekbfix">
                <h2 id="ultranav">Ultra Sub Navigation</h2>
                <ul>
                <li><a href="#content">Content title</a></li>
                <li><a href="/ultraa/">Ultra A</a></li>
                <li><a href="/ultrab/">Ultra B</a></li>
                <li><a href="/ultrac/">Ultra C</a></li>
                ...
                <li><a href="/ultraj/">Ultra J</a></li>
                </ul>
                </div>
                <div>
                <h2 id="content">Content title</h2>
                <p>Now that I have your attention...</p>
                </div>

CSS:

コード例:


              div.iekbfix {
                width: 100%;
                }

参考リソース

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

Skip Navigation Links

検証

手順

繰り返されるコンテンツのブロック、又はブロック内の最初のリンクの前に、リンクが最後のフォーカス可能なコントロールであることを確認する。
リンクの説明がブロックをスキップすることを伝えることを確認する。
リンクが常に表示されている、又はキーボードフォーカスを受け取ったときに表示されることを確認する。
リンクをアクティブにした後、キーボードのフォーカスがそのブロックの直後のコンテンツに移動することを確認する。

期待される結果

上記の全ての結果が真である。

G124: ページの先頭に、コンテンツの各エリアへのリンクを追加する

適用 (対象)

リンク機能を提供するウェブコンテンツ技術すべて。

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.1 (ブロックスキップ)
- クイックリファレンス 2.4.1 (ブロックスキップ)
- 達成基準 2.4.1 (ブロックスキップ)を理解する

解説

この達成方法の目的は、コンテンツの異なるセクションへのリンクのリストを提供することによって、文書のブロックをバイパスするメカニズムを提供することである。このリストにある複数のリンクは、コンテンツの最初にある小さな目次のようなものであり、その中のリンクはコンテンツ内のさまざまなセクションへフォーカスを設定する。この達成方法は、ポータルサイトのような多くの独立したセクションがあるページに対して特に有効である。これはセクション内でのブロックをスキップする他の達成方法と組み合わせることもできる。

事例

事例 1

サイト内のウェブページはすべて、そのページのメインコンテンツ、検索フィールド、及びナビゲーションバーにナビゲートする三つのリンクで始まる。

参考リソース

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

Skip Navigation Links

検証

手順

この目的のために提供されているリンク一式にある各リンクに対して:

ウェブページの中でそのリンクより前にあるコントロールの、その一式にある他のリンクだけであることを確認する。
各リンクの説明がコンテンツ内のあるセクションへリンクすることを伝えていることを確認する。
そのリンクが常に表示されている、又はキーボードフォーカスを受け取ったときに表示されるかのいずれかであることを確認する。
リンクをアクティブにすると、コンテンツの目的のセクションへフォーカスを移動することを確認する。

期待される結果

上記全ての結果が真である。

G125: 関連するウェブページへナビゲートするリンクを提供する

適用 (対象)

リンクを含む全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.5 (複数の手段)
- クイックリファレンス 2.4.5 (複数の手段)
- 達成基準 2.4.5 (複数の手段)を理解する

解説

この達成方法の目的は、関連するウェブページへのリンクを提供することによって利用者が追加情報の場所を特定できるようにすることである。それは、達成基準 2.4.5 の実装に十分なコンテンツを配置するための一連の達成方法の一つである。リンクは、World Wide Web の基本的な構成要素であり、ウェブを相互接続されたウェブコンテンツにするメカニズムである。大半のウェブコンテンツ制作者は、ウェブページを制作する場合に無意識にこの技術を用いている。

事例

事例 1

ウェブコンテンツアクセシビリティガイドライン 2.0 は、ガイドラインと達成基準の中で使われる用語を定義したドキュメントへのリンク、異なる達成基準をどのように満たすかを説明したドキュメントへのリンク、そのセクションの異なるサブセクションへのリンクを含む各セクションの目次、及び Comparison of WCAG 1.0 checkpoints to WCAG 2.0 へのリンクを含んでいる。利用者がこのドキュメントを拾い読みするときは、これらのリンクをたどって関連情報を探すことができる。

参考リソース

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

Architecture of the World Wide Web, Volume One

検証

手順

ウェブページ内の各リンクに対して:

そのリンクが関連する情報へのリンクへつながっていることを確認する。

期待される結果

1.の結果が真である。

G126: 他の全てのウェブページへのリンク一覧を提供する

適用 (対象)

リンク機能を提供する全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.5 (複数の手段)
- クイックリファレンス 2.4.5 (複数の手段)
- 達成基準 2.4.5 (複数の手段)を理解する

解説

この達成方法の目的は、個々のウェブページを一組として全てのウェブページへのリンク一覧を提供することである。達成基準 2.4.5 を実装するのに十分なコンテンツを配置するための一連の達成方法の一つである。この達成方法は、小規模なウェブページに対してのみ効果がある; リンク一覧がウェブページ内の残りのコンテンツより長い場合、利用者がウェブページを理解して使うことをより困難にするかもしれないからである。

注記: 達成基準 2.4.1 は、このリンクの一覧をスキップするための達成方法を要求している。

事例

事例 1

家族のウェブサイトには、家族の構成員全てのウェブサイト (サブサイト) がある。個々のページには、他の家族構成員のウェブサイトへのリンク一覧がある。

事例 2

電子ブックでは、各章が別々のウェブページに分けられている。個々のウェブページは、本の中の全ての章へのリンクを含む小さな目次で始まる。

参考リソース

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

検証

手順

個々のウェブページに、サイト内の他のウェブページへのリンクの一覧が含まれていることを確認する。
一覧内のリンクが対応するウェブページにつながっていることを確認する。
一覧には、サイト内の全てのウェブページに対するリンクが含まれていることを確認する。

期待される結果

上記全ての結果が真である。

G127: あるウェブページと、より大きな一連のウェブページとの関係性を特定する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、利用者がそのウェブページと同じ一式 (例: 同じウェブサイト) にあるウェブページとの関係性を特定できるようにすることである。場合によっては、プログラムが解釈できるように実装することが可能である。例えば、HTML では、link 要素の rel 属性を用いることができる。また、ウェブページのタイトルに関連する情報を含めることによって、関係性を示す情報を提供することもできる。

事例

事例 1: サブサイト名を含んだウェブページのタイトル

ある大規模なウェブサイトに、数々のウェブコンテンツ技術に関するチュートリアルとリファレンスがある。各ウェブページのタイトルには、そのサイトを提供している組織名とサブサイト名とがある。

事例 2: 特定できる情報を含んだメタデータ

あるウェブページには、それが文書一式の目次であることを示すメタデータがある。その文書一式にある各文書のメタデータは、一式の中におけるその文書の位置付けを特定しており、目次への参照を提供している。

事例 3: オンライン教科書の各章

あるオンライン教科書が幾つかの章に分けられている。各ウェブページのタイトルには、教科書のタイトルに加えて、その章の章番号とタイトルがある。

参考リソース

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

検証

手順

ウェブページのタイトルが、そのウェブページの属するウェブページ一式との関係性を示しているかどうかを確認する。
ウェブページに、そのウェブページの属するウェブページ一式との関係性を特定するメタデータが含まれているかどうかを確認する。

期待される結果

1. 又は 2. の結果が真である。

G128: ナビゲーションバー内で現在位置を示す

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.8 (現在位置)
- クイックリファレンス 2.4.8 (現在位置)
- 達成基準 2.4.8 (現在位置)を理解する

解説

この達成方法の目的は、ナビゲーションに関するユーザインタフェースを通じて、現在位置の情報を提供することによって、利用者が現在位置を確認しやすくすることである。この達成方法は、順序立てて処理すべきタスクを、複数のウェブページで段階的に説明している場合に役立つ。このような表示の提供は、利用者が一連の文書の中で自分の位置を正しく把握するのに役立つ。アイコンやテキストを追加したり、その項目の状態を変化させることで、位置を示すことができる。

事例

事例 1

あるウェブページにタブパネル型のナビゲーションが設置してある。タブのリストは横並びに表示されている。現在のコンテンツはタブの下のパネルに表示される。利用者がタブを選択すれば、選択したタブに合わせてパネル内のコンテンツが更新される。さらに、パネルを開いたことを示すために、選択したタブの背景色は初期状態とは異なる色に変化し、テキストの横にチェックマークアイコンが表示される。チェックマークアイコンには、適切なテキストによる代替を指定してある。

事例 2

あるウェブページのレイアウトに、フレームセットと複数のフレームを用いている。フレームの一つをナビゲーションのためのフレームとし、もう一方のフレームにはウェブサイトのコンテンツを表示させている。利用者がナビゲーションフレーム内のリンクを選択したら、そのリンクに合った情報がコンテンツフレームに表示される。ナビゲーションフレーム内で選択した項目には、それが選択したトピックであることを示すためにアスタリスクが追加される。

事例 3

あるウェブサイトのナビゲーションバーは、複数のリンクのリストとして設置されている。ナビゲーションバーは、全てのウェブページに設置してある。利用者がナビゲーションバー内のリンクにフォーカスするかマウスオーバーしたときに、リンクの背景色が変化する。マウスオーバー又はフォーカス時のこのスタイリングの変更は、ウェブページのカスケーディングスタイルシートで指定する。リンクからフォーカスが外れたら、通常のリンクのスタイルに戻る。別のページを見るためにリンクをアクティブにした場合、選択したリンクは動作しないようになる。このリンクを選択した結果として、現にそのページが表示されているからである。背景色の変更は、選択したリンクであるという視覚的な通知を利用者に与える。リンクが動作しないようにすることで、現在選択しているトピックであるという情報を全ての利用者に提供する。

参考リソース

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

検証

手順

ウェブページ一式にナビゲーションコンポーネントが繰り返さている場合:

ナビゲーションユニット内で、現在選択されている項目の指示が利用者に与えられていることを確認する。
選択されている項目が表示されているコンテンツと一致することを確認する。

期待される結果

1. 及び 2. の結果が真である。

G130: 説明的な見出しをつける

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.6 (見出し及びラベル)
- クイックリファレンス 2.4.6 (見出し及びラベル)
- 達成基準 2.4.6 (見出し及びラベル)を理解する

解説

この達成方法の目的は、ウェブコンテンツ内の見出しがコンテンツの内容を表すようなものにすることである。コンテンツの内容が分かるような見出しやタイトル (「G88: ウェブページに対して、コンテンツの内容が分かるページタイトルを提供する」参照) を用いることで、利用者に対してコンテンツの概要と構成を提示することができる。内容を表す見出しをつけることで、そのセクション (節) のウェブページ中の位置づけと、他のセクションとの関係を明確にすることができる。

内容を表す見出しがあれば、利用者は目的のコンテンツを見つけることや、ウェブページ内のどの部分を読んでいるのかを知ることが容易になる。

コンテンツ制作者は、最も重要な情報を各見出しの先頭に配置することを検討すると良いだろう。これによって、利用者は斜め読みをして必要な情報を見つけることが容易になる。特に、見出しから見出しへのナビゲーションが可能なブラウザや支援技術を用いている場合には有効である。

事例

事例 1

災害対策を示す HTML ページで、以下のような見出しが使われている:

コード例:


              <h1>Disaster preparation</h1>
                <h2>Flood preparation</h2>
                <h2>Fire preparation</h2>

レベル 2 の見出しは、先頭に内容を識別できる情報が配置されていることに注意されたい。 (すなわち、「対策 : 洪水」、「対策: 火災」などとはなっていない。)

事例 2

ある町について書かれた短い記事がある。この記事は、町の起こり、拡大、そして現状に関する詳しい説明を含んでいる。ウェブページのタイトルは「私たちの町の歴史」である。最初のセクションのタイトルは「我が町の始まり」で、2 番目のセクションのタイトルは「我が町の拡大」である。3 番目のセクションのタイトルは「今日の我が町」で、このセクションには、「町の人々」、「町の組織」、「町の施設」というサブセクションがある。

参考リソース

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

検証

手順

ウェブページに見出しが含まれているかどうかを判断する。
各見出しがコンテンツのセクションを特定することを確認する。

期待される結果

2. の結果が真である。

G131: 説明的なラベルを提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.6 (見出し及びラベル)
- クイックリファレンス 2.4.6 (見出し及びラベル)
- 達成基準 2.4.6 (見出し及びラベル)を理解する
達成基準 3.3.2 (ラベル又は説明)
- クイックリファレンス 3.3.2 (ラベル又は説明)
- 達成基準 3.3.2 (ラベル又は説明)を理解する
注記: この達成方法は、達成基準 3.3.2 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 3.3.2 を理解するを参照すること。

解説

この達成方法の目的は、ウェブコンテンツ内のあらゆるインタラクティブなコンポーネントに対するラベルにより、コンポーネントの目的を明確にすることである。そのウェブコンテンツ技術において、ラベルとインタラクティブなコントロールを関連付けるための適切な達成方法によって、支援技術はラベルを認識し利用者に提示できるようになる。そのため、利用者はコントロールの目的を認識することができる。ラベルは、インプットが要求されるテキスト又はテキストシンボルに使用されても良い。

事例

事例 1: ズームイン及びズームアウトのコントロールのあるオンライン地図

ある都市の地図をウェブアプリケーションで提供している。利用者は「ズームイン」を使ってより詳細な地図が見られ、「ズームアウト」で都市の広い地域を見ることができる。マウスとキーボードのいずれでも操作することができる。コントロールには「ズームイン (Ctrl + Shift + L)」と「ズームアウト (Ctrl + Shift + R)」というラベルが提供されている。

事例 2: 利用者の名前を入力させるフォーム

利用者の名前を入力させるフォームがある。そのフォームには、姓と名を入力するために二つのフィールドがある。一つめのフィールドには「姓」というラベルがあり、二つめには「名」というラベルがある。

事例 3: 必須入力のあるフォーム

必須の入力項目がいくつかある注文票がある。必須入力のフィールドには、フィールドの項目名に加えて「(必須)」と括弧書きされている。

参考リソース

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

H90: label 要素又は legend 要素を使用して、必須のフォームコントロールを明示する

検証

手順

コンテンツ中の各インタフェースコンポーネントに対して:

インタフェースコンポーネントの目的を特定する。
必要なラベルが存在することを確認する。
各ラベルがコンポーネントの目的を明確に示していることを確認する。

期待される結果

2. 及び 3. の結果が真である。

G133: 複数部分で構成されるフォームの最初のページに、利用者がセッションの制限時間を延長又は解除を要求できるチェックボックスを提供する

適用 (対象)

複数の画面で構成されるフォームのあるコンテンツ

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.1 (タイミング調整可能)
- クイックリファレンス 2.2.1 (タイミング調整可能)
- 達成基準 2.2.1 (タイミング調整可能)を理解する

解説

この達成方法の目的は、複数の画面で構成されるフォームを記入するにあたって時間の延長を要求できるチェックボックスを提供することにより、障害のある利用者が途中まで記入した内容を失うリスクを最小化することである。このチェックボックスによって、利用者は、具体的にどれだけの時間を追加したいか (例えば 15 分など)、あるいは無限に延長したいかを要求できるようになる (ただし、利用者のプライバシーやネットワークのセキュリティを危険にさらす恐れがある場合、無限に延長できるようにすることは適切ではない)。

事例

事例 1: 具体的な延長時間を要求するチェックボックス

五つのパートで構成されるフォームの最初のパートがウェブページに表示されている。フォームの記入方法に関する一般的な説明のすぐ後に、「フォームの各パートの記入に必要な時間を 15 分延長する」というラベルのチェックボックスがある。

事例 2: 無限の延長を要求するチェックボックス

三つのパートで構成されるフォームの最初のパートがウェブページに表示されている。各パートにそれぞれ 10 個以上の入力項目がある。それらの入力項目のなかには、リンクをたどって付加的な情報を見なければならないものもある。フォームの記入方法に関する一般的な説明のすぐ後に、「フォーム記入に必要な時間を無限に延長する。また、最後のパートを記入する前にフォームの記入をやめる場合は、ウェブブラウザを閉じなければならないことに同意する。」というラベルのチェックボックスがある。

検証

手順

ウェブページに、マルチパートフォームの最初のパートを含む場合:

ウェブページにフォーム入力を完了させるための追加時間を要求するチェックボックスがあることを確認する。
チェックボックスが選択されている場合、フォーム入力を完了させるための追加時間が提供されていることを確認する。

期待される結果

全ての結果が真である。

G134: ウェブページをバリデートする

適用 (対象)

全てのマークアップ言語及びその他の多くのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 4.1.1 (構文解析)
- クイックリファレンス 4.1.1 (構文解析)
- 達成基準 4.1.1 (構文解析)を理解する

解説

この達成方法の目的は、正式な仕様に則ってバリデートされていないコードにしばしば起因するウェブページの曖昧さをなくすことである。ウェブコンテンツ技術及びそのバージョンを特定するために、それぞれのウェブコンテンツ技術に備えられているメカニズムを用いて、そのウェブコンテンツ技術の正式な仕様に照らし合わせてウェブページをバリデートする。対象となるウェブコンテンツ技術にバリデータがある場合、コンテンツ制作者/開発者はそれを使うことができる。

通常は、バリデーションによって曖昧さ (及びその他の問題点) を排除することが可能である。これは、バリデーションに不可欠なステップの一つが、ウェブコンテンツ技術のマークアップ (マークアップ言語) 又はコード (他のウェブコンテンツ技術) が適正に使用されているかどうかをチェックすることだからである。バリデーションは、必ずしも仕様への完全な準拠をチェックするものではないが、コンテンツを仕様に照らし合わせて自動チェックするには最適な手段である。

事例

事例 1: HTML のバリデーション

HTML ページに文書型宣言 (!DOCTYPE として記述されることが多い) があり、その文書型宣言で指定された HTML のバージョンに対して妥当 (Valid) である。コンテンツ制作者/開発者は、オフライン又はオンラインのバリデータ (下記「参考リソース」を参照) を使用して、この HTML ページの妥当性をチェックできる。

事例 2: XML のバリデーション

XHTML、SVG、SMIL 及びその他の XML をベースしたドキュメントが、文書型定義 (DTD) 又はその他のタイプの XML スキーマを参照している。コンテンツ制作者/開発者は、オンライン又はオフラインのバリデータ (エディタに内蔵されている検証ツールを含む) を使用して、この XML ドキュメントの妥当性をチェックできる。

事例 3: Ant のバッチによるバリデーション

XML ファイルのバリデーションをバッチで行う際には Apache Ant の xmlvalidate タスクを使用することができる。次の Apache Ant ターゲットは、(Ant のビルドファイルに相対する) ディレクトリ dev\\Web 内にある拡張子 .xml のファイルをバリデートするシンプルな例である。

コード例:


   <target name="validate-xml"> 
   <xmlvalidate lenient="no"> 
   <fileset dir="dev/web" includes="*.xml" /> 
   </xmlvalidate> 
   </target>

参考リソース

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

訳注: 以下に示される参考リソースは、W3C HTML5 勧告以前に作成されたものが多数であり、その多くは HTML5 への対応がなされていないと考えられる。そのため、WAIC では翻訳を行っていない。

Do not forget to add a doctype by the W3C Quality Assurance Initiative explains what doctypes are and why you should use them.
Recommended DTDs to use in your Web document by the W3C Quality Assurance Initiative is a list of commonly used declarations.
How do I validate my code or check for possible errors? describes the tools in the free editor HTML-Kit for checking HTML, CSS and XML.

HTML 及び XHTML のバリデーション

The W3C Markup Validation Service by the World Wide Web Consortium allows you to validate HTML and XHTML files by URI, by file upload and by direct input of complete HTML or XHTML documents. There are also separate pages with an extended interface for file upload and for validating by URI (advanced options such as encodings and document types).
Installation Documentation for the W3C Markup Validation Service explains how to install this service (for example for use on an intranet).
WDG HTML Validator by the Web Design Group allows you to enter a URI to validate single pages or entire sites. There are also versions to validate Web pages in batch mode (by specifying one or more URIs of HTML documents to validate), by file upload and by direct input of HTML code.
Offline HTMLHelp.com Validator is a tool for Unix users; it is the off-line version of the online WDG HTML Validator.
Off-line HTML Validator – A clipbook for NoteTab by Professor Igor Podlubny is an extension for the programming editor NoteTab. It uses James Clark's open-source SGML parser, which is also used by the W3C Markup Validation Service.
Do-it-yourself Offline HTML Validator by Matti Tukiainen explains how you can create a simple validator with James Clark's SGML parser on Windows.
Validating an entire site by Peter Kranz explains how you can install a modified version of the W3C Markup Validation Service that outputs validation results as XML on Mac OS. Source code (in Perl and Python) is available.
HTML Validation Widget adds a "Validate HTML" option to Internet Explorer's context menu and validates the current HTML document with the Web Design Group's HTML Validator.
Can I use the W3C MarkUp Validation Service to validate HTML? explains how you can validate HTML from within the free editor HTML-Kit.
HTML/XML Validator is an online repair tool for HTML and XHTML based on Tidy and PHP 5. It is available in several languages but it is not a real validator.
Fix Your Site With the Right DOCTYPE! by Jeffrey Zeldman explains what HTML and XHTML doctypes work and what their effect is on the rendering mode of a few browsers.
Modifying Dreamweaver to Produce Valid XHTML by Carrie Bickner.
XHTML-Schemata für FrontPage 2003 und Visual Studio .NET by Christoph Schneegans is a German article that explains how the W3C XML Schemas for XHTML 1.0 can be used in FrontPage 2003 and Visual Studio .NET to create valid code.
Nvu is a free and open-source Web authoring tool for Windows, Macintosh and Linux that can call the W3C HTML Validation Service.
Amaya by the World Wide Web Consortium is a free and open-source Web authoring tool with support for HTML, XHTML, CSS, SVG and MathML that alerts you to validity errors when you save a document.
Web Developer Extension is an extension for Mozilla, Firefox and Flock by Chris Pedrick that allows you to use the W3C Validation Services for HTML and CSS.

Validating XML

XML Validator - A Document Validation Service by JavaView allows you to check wellformedness and validity of XML files, by file upload or by direct input of XML code.
Apache Ant's XMLValidate Task can be used to validate XML-based documents. This tool can be used to validate entire directories (and subdirectories) of XML files.
XML Schema Validator by Christoph Schneegans is an online tool that allows you to validate XML (and XHTML) files by URI, by file upload, by direct input of complete XML documents, and by direct input of XML code fragments. A bookmarklet that allows you to validate the page currently displayed in your browser is also available. This validator claims to be more accurate than the W3C validator.
XML Schema Validator by CoreFiling is an online tool that allows you to validate an XML file against a W3C XML Schema, both of which can be uploaded.
NetBeans: Working with XML, Part 1 and NetBeans: Working with XML, Part 2 by Tim Boudreau and others, explains how to enable XML support, validation and other related functionality in the open-source NetBeans framework.
Schema Validator: this is a validator that allows you to paste XML and W3C XML Schema code into text boxes to validate XML code.
XML Nanny: a graphical tool for validating XML and XHTML, with support for DTD, W3C XML Schema, RELAX NG and Schematron (Max OX X).

Note that many programming editors, XML editors and integrated development environments (IDEs) can validate XML files. These include the following free and/or open-source tools:

the programming editor JEdit with the XML and SideKick plugins, which supports DTDs and W3C XML Schemas,
the “workbench" Eclipse with the Web Tools Platform,
the Web authoring tool SCREEM for the Gnome desktop environment, which supports DTDs,
the XML editor Jaxe, which validates XML files with Apache Xerces,
the XML editor Xerlin, which supports DTDs and to some extent W3C XML schema,
the XML editor xmloperator, which supports DTDs and RELAX NG schemas,
Emacs in nXML mode (see the YahooGroup Emacs nXML Mode),
the XML editor Pollo, which supports DTDs, W3C XML Schemas and RELAX NG schemas, and is best suited for tree-like XML files.

(今のところ、なし。)

検証

手順

HTML、SGML ベース及び XML ベースのウェブコンテンツ技術に対して:

それぞれのページ又はドキュメントをバリデーションを行うパーサーで読み込む。
バリデーションエラーがないことを確認する。

その他のウェブコンテンツ技術に対して:

用いているウェブコンテンツ技術に対してバリデーションの手順が存在する場合は、それに従う。

期待される結果

HTML、SGML ベース、及び XML ベースのウェブコンテンツ技術に対して:

2. の結果が真である。

G135: 名前 (name) 及び役割 (role) を公開し、利用者が設定可能なプロパティを直接設定可能にして、変更の通知を提供するためのウェブコンテンツ技術のアクセシビリティ API 機能を使用する

適用 (対象)

アクセシビリティ API と連動するようにプログラムされた標準コンポーネントを持つプログラミングウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- クイックリファレンス 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- 達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )を理解する

解説

この達成方法の目的は、支援技術が代替のユーザインタフェースを通して利用者に等価の情報を伝えることができるように、支援技術がウェブコンテンツを理解できるようにすることである。

コンテンツは、マークアップ言語を用いず、プログラミング言語又はツールを用いて制作されることがある。多くの場合、これらのウェブコンテンツ技術には、既にアクセシビリティ API と連動するようにプログラムされたインタフェースコンポーネントがある。コンテンツ制作者がそういったコンポーネントを使用して、プロパティ (例えば名前など) を記述すれば、生成されたコンテンツのユーザインタフェースコンポーネントは支援技術に対してアクセシブルとなる。

事例

事例 1

ウェブページがアプレットを作るために Java を使用している。Java Swing オブジェクト (例えばプッシュボタン) が使われているのは、Java で書かれた支援技術からアクセスできる標準搭載のアクセシビリティプロパティ、及び Java Access Bridge とともに OS のアクセシビリティ API を用いる他の言語で書かれたアクセシビリティプロパティを持っているためである。コンテンツ制作者がそのコンポーネントに対して値を記述することによって、そのコンポーネントは支援技術にとってアクセシブルなものとなる。

参考リソース

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

(今のところ、なし。)

検証

手順

アクセシブルなユーザエージェントを用いてコンテンツをレンダリングする。
各ユーザインタフェースコンポーネントを評価するために、ユーザエージェントのアクセシビリティ API に対応して設計されたアクセシビリティツールを使用する。
各インタフェースコンポーネントの名前 (name) 及び役割 (role) が、そのツールによって検出されることを確認する。

期待される結果

各インターフェースコンポーネントについて、3. の結果が真である。

G136: 不適合なウェブページの先頭に、適合している代替版を指すリンクを提供する

適用 (対象)

本来のコンテンツは WCAG に適合していないが、WCAG に適合している代替版は存在している。この達成方法を用いることができるのは、ウェブコンテンツ技術が代替版へのアクセシブルなリンクを作ることを可能としている場合のみである。

これは、次の達成基準に関連する達成方法である:

適合要件 1 (適合レベル)

解説

この達成方法の目的は、本来のコンテンツ又は利用者が特定の URI に訪れた時に遭遇するデフォルトのコンテンツが WCAG に適合していない場合、利用者が WCAG に適合している代替コンテンツにアクセスできるようにすることである。代替ページ又は適合している代替版は、適合するためにいくつかのデザイン又は機能的な譲歩を作る可能性があるが、適合している代替版にするためには定義において記された要件を満たさなければならない。「適合している代替版」の定義とは:

適合している代替版 (conforming alternate version)

以下の事項を満たす版のことを指す:

指定されたレベルで適合しており、かつ
同じ情報及び機能のすべてを同一の自然言語で提供しており、かつ
不適合コンテンツと同時に更新されていて、かつ
以下に挙げる事項のうち少なくとも一つを満たしていること:
1. アクセシビリティサポーテッドなメカニズムを用いて、不適合ページから適合版へ到達できる。もしくは、
2. 不適合版に到達できるのは、適合版からのみである。
3. 不適合版に到達できるのは、適合版に到達するメカニズムも提供している適合ページからのみである。

注記 1: この定義において、「到達できるのは……からのみ」とは、利用者が適合版から来ていない限り、不適合ページに「到達する」 (読み込む) のを防ぐ条件付きリダイレクトのような何らかのメカニズムがある、ということを意味する。

注記 2: 代替版は、元のページと一対一で対応している必要はない (例えば、適合している代替版は複数のページであってもよい)。

注記 3: 複数の言語版が利用できる場合、各言語版に対して、適合している代替版を提供する必要がある。

注記 4: 様々な技術環境、又は利用者層に対応するために、複数の代替版を提供してもよい。この場合、各版は可能なかぎり適合したものでなければならず、適合要件 1 を満たすためには、そのうちの一つの版が完全に適合したものでなければならない。

注記 5: 不適合版と同じように自由に利用可能であるかぎり、適合している代替版は、適合宣言の範囲に含まれている必要はなく、同一のウェブサイト上で提供されている必要もない。

注記 6: 代替版は、元のページを補助して理解を高める補足コンテンツと混同されないようにすべきである。

注記 7: コンテンツ内で利用者が設定を行うことで適合版が作り出される仕組みは、その利用者の設定に用いられている手法がアクセシビリティサポーテッドであるかぎり、代替版への到達メカニズムとして条件を満たしているといえる。

Understanding Conforming Alternate Versions を参照。

この実装方法を使用している際、ページの最初に代替コンテンツへの WCAG に適合したリンクを配置することで、利用者がそのリンクをすぐに見つけることができ、適合している代替版に移動することができるようになる。利用者がどこからそのサイトに入ったかに関係なく、利用者が常に代替版を見つけることができるようにするためには、特定のレベルで適合していないページには適合している代替版へのリンクを含めることである。

事例

ウェブサイト上で宣言しているレベルで WCAG に適合していない各ページにおいて、ページの最初に「アクセシブルバージョン」と書かれたリンク (又はリンクの目的を適切に表した他のリンクテキスト) がある。このリンク先は、宣言のレベルで WCAG に適合している代替版のページである。

検証

手順

宣言した適合レベルで WCAG に適合していないページを特定する。
そのページには、そのページの適合している代替版へのリンクが含まれているかどうかを確認する。
代替版が、オリジナルページの適合している代替版であり、かつ要求された適合レベルで WCAG 2.0 に適合しているかどうかを判断する。

期待される結果

2. と 3. の両方の結果が真である。

G138: 色の手がかりを用いるときは必ず、セマンティックなマークアップを使用する

適用 (対象)

色及びテキストをサポートするウェブコンテンツ技術すべて。

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

解説

この達成方法の目的は、色とセマンティックなマークアップを組み合わせて、情報を伝達することである。ほとんどの利用者はコンテンツをすばやく読み取り、色を用いて伝達された情報をコンテンツから見つけることができる。色を見ることができない利用者に対しては、セマンティックなマークアップによって異なるタイプの手がかりを提供することができる。それによって、ユーザエージェントは、例えば、異なるタイプの構造に対しては異なる視覚的提示を用いる、又は聴覚的提示において異なる音声もしくは音の高さを用いることによって、このタイプの構造を利用者に対して知覚可能にすることができる。

ほとんどのユーザエージェントは、セマンティックなマークアップを用いて指定されたテキストを視覚的に区別する。支援技術の中には、適切なセマンティックマークアップを用いて制作されたコンテンツの特徴を定めるメカニズムを提供しているものもある。

訳注: WAIC では G138 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: G138 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例

事例 1: :必須のフォーム項目に対して、色と強調を用いる

HTML のフォームにいくつかの必須項目がある。必須項目のラベルは赤で表示されている。加えて、各ラベルのテキストは強い強調を示すために strong 要素でマークアップされている。フォーム入力の説明文には、「すべての必須項目は赤で表示されており、強調されている」とあり、事例が添えられている。

訳注: MDN の strong 要素で示されているように、古い HTML では strong 要素を単により強い強調としていたが、現在の HTML では strong を重要性を表すものと定義している。

参考リソース

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

検証

手順

情報を伝達するために色の違いが使用されているコンテンツに対して:

セマンティックなマークアップを通して同じ情報が入手可能であることを確認する。

期待される結果

1.の結果が真である。

G139: 利用者がエラー箇所に移動できるメカニズムを作成する

適用 (対象)

利用者のデータ入力を受け付け、そのフォーマット、値及び／又は入力の種類に制限があるコンテンツ

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、利用者によって提供された情報が受け付けられない場合に、入力エラーの修正を支援することである。これには、必須入力欄が空欄の場合と、入力欄に正しくない情報が入力された場合とが含まれる。利用者による入力データをバリデートした結果、入力エラーが検出された場合に、この入力エラーの内容と場所に関する情報をテキストで提供することによって、利用者は問題のある箇所を特定することができる。一つのアプローチとして、サーバーサイドでのバリデーションを用いて、フォームを再表示し (すでに入力されたデータも含む)、ページの上部にテキストでの説明文を表示して、エラーがあったことを知らせるとともに問題の内容を説明して、利用者が問題のあった項目を簡単に見つけられるような方法を提供することがある。

事例

事例 1: サーバーサイドのエラーチェック

利用者がフォーム項目に無効なデータを入力して、そのフォームを送信すると、サーバーがフォームを利用者に再提示する。利用者の入力したデータはそのまま表示された状態で、ページの上部に入力エラーがあったことをテキストで明確に示している。このテキストは、エラーの内容を説明していて、どの項目に問題があったのかを明確に示しているため、利用者はその項目へ容易に移動し、問題を修正することができる。

事例 2: ポップアップを用いたクライアントサイドのエラーチェック

利用者がフォーム項目に無効なデータを入力して、そのフォームを送信しようとする。クライアントサイドのスクリプトがエラーを検出し、送信をキャンセルした上で、そのフォームにエラーを説明するテキストとエラーのある項目へのリンクを表示する。また、このスクリプトは、問題のある項目のラベルを変更して、それを強調する。

事例 3: ポップアップを用いないクライアントサイドのエラーチェック

利用者がフォームを送信しようとした時、新たなページに遷移させる代わりに、スクリプトが自動的に「エラーが発生しました」というテキストにフォーカスする。エラーを説明するメッセージリストにリンクし、一つ一つの項目がエラー箇所にリンクをする。また、エラー箇所からエラーメッセージリストへのリンクも設置されている。このプロセスが必要な限り繰り返される。

検証

手順

フォームに記入し、故意に必須項目を空白にして、他のフィールドに入力エラーを作った状態でフォームを送信する。
必要なデータが欠落しているフィールドを特定するテキストメッセージが提供されていることを確認する。
入力エラーのあるフィールドを特定するテキストメッセージが提供されていることを確認する。
欠落しているデータのメッセージから、必要なデータが欠落している各フィールドへのリンクがあることを確認する。
エラーメッセージからエラーリストへのリンクがあることを確認する。

注記: 達成基準 3.3.2 では、入力エラーが検知され、修正の示唆が既知であり、セキュリティ又はコンテンツの目的が脅かされることなく提供できる場合、利用者に修正の示唆を提供するよう求めている。

期待される結果

2. の結果が真である場合、4. の結果が真である。
3. の結果が真である場合、5. の結果が真である。

G140: 異なる提示を可能にするために、情報と構造を表現から分離する

適用 (対象)

あらゆるウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、表現的なエンコーディングからコンテンツの構造的なエンコーディングを論理的に分離することによって、支援技術のコンテンツとのインタラクションを容易にすることである。構造的なエンコーディングとは、見出し、段落、リスト、テーブルなどの要素を指定することであり、そういった目的のために用意されたウェブコンテンツ技術の機能を使用することによって行われる。一方、表現的なエンコーディングとは、書体、色、サイズ、位置、ボーダーのような書式効果の指定であり、ウェブコンテンツ技術の機能によってもサポートされている。

表現的な特性は視覚的に構造を暗示する、つまり利用者は用いられている書式設定の慣例から、見出し、段落、リストなどを判断できる。その一方で、これらの特性は、支援技術によるそのページとの効果的なインタラクションに十分なほど曖昧さのないように構造をエンコードしているわけではない。独立した構造、機能、及び提示レイヤーを提供することにより、書式設定によって暗示されたセマンティクスが、構造レイヤーを通してプログラムによる解釈が可能になる。

この達成方法を用いることによって、ユーザエージェントでは次のことが可能になる:

セクションの並び替え、又はセクションのリストやリンクのリストの生成のように、コンテンツの既存の構造をベースにした意味ある構造の変換を実行する。
表現的な情報のみに基づいて支援技術が決定できない、構造上の特徴に基づいたコンテンツとのインタラクションをサポートする。たとえば、リスト項目の数を示す、又はリストの終了位置までスキップすることによって、リストとの特別なインタラクションを提供することは望ましいかもしれないが、これが可能なのはリストの構造がリストの表現に加えてコード化されている場合のみである。
構造の特性に付随した代替の表現ルールを代用することによって、コンテンツの表現を改良する。

事例

事例 1: CSS 付きの HTML

HTML ドキュメントは、段落、リスト、見出しなど HTML の構造特性を用いていて、書体の変更、レイアウトのヒントなどのような表現的な特性を用いることを避けている。そして、構造的なプロパティに基づいてドキュメントをフォーマットするために、CSS が用いられている。HTML においてよく考えて設計された class 属性は、必要に応じて構造的なマークアップの意味を拡張し、より柔軟なフォーマットを CSS によって可能にする。支援技術は、CSS を代用又は拡張して表現を改良する、もしくは CSS を無視して構造的なエンコーディングと直接やりとりをする。

事例 2: タグ付き PDF

PDF 文書は、書式設定情報が組み込まれているコンテンツでほとんど成り立っている。構造に関する情報は、XML のようなタグを使用しているドキュメントの別セクションの中で提供されており、これは「タグ付き PDF」と呼ばれている。それらのタグの中にある情報は、支援技術が意味のある構造の変換に用いる (例えば、セクションのリストを生成する) ため、又は構造的な特徴に基づいたコンテンツとのインタラクションをサポートする (例えば、フォームの先頭にジャンプする) ために使用可能である。

C29: 適合している代替版を提供するために、スタイルスイッチャーを使用する

検証

手順

ドキュメントのエンコーディングを調べる。
構造情報と機能が明示的に提供され、表象的な情報から論理的に分離されていることを確認する。

期待される結果

2. の結果が真である。

G141: 見出しを用いてウェブページを構造化する

適用 (対象)

セクションで構成されたコンテンツのあるウェブページ

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、それぞれのセクションにそれを識別できる見出しがついているようにすることである。達成基準 1.3.1 では見出しがプログラムで解釈可能な方法でマークアップされていることを要求している。

HTML においては、これは見出し要素 (h1, h2, h3, h4, h5, h6) によって実現されうる。これによりユーザエージェントは自動的にセクションの見出しを識別できる。他のウェブコンテンツ技術では、また異なる方法で見出しを識別する。ページ内の移動と文書の全体的構造の理解を助けるには、コンテンツ制作者は見出しを適切に入れ子にするべきである (たとえば h1 には h2 が続き、h2 には h2 か h3 が続き、h3 には h3 または h4 が続き……といったように)。

訳注: MDN の <h1>–<h6>: HTML の見出し要素 - アクセシビリティへの配慮で言及されているように、見出しレベルを飛ばしてページを作成する (例えば、h1 要素の次に h3 要素を置く) と、スクリーンリーダーの利用者がそのページの見出しをナビゲートするときに、ページには存在しない h2 要素を誤って飛ばしてしまったのではないかと誤解する恐れがあることに注意する。

事例

事例 1: HTML のページを構造化するために用いられた見出し

ある調理法を紹介するページでは、h1 要素により全体とタイトルを示し、h2 要素で大項目としてサラダ油による調理とバターによる調理を示し、h3 要素で油による調理の詳細なサブセクションを示している。

コード例:


              <html xmlns="http://www.w3.org/1999/xhtml">
                <head>
                <title>Cooking techniques</title>
                </head>
                <body>
                <h1>Cooking techniques</h1>
                ... some text here ...
                <h2>Cooking with oil</h2>
                ... text of the section ...
                <h3>Sautéeing</h3>
                ...
                <h3>Deep frying</h3>
                <h2>Cooking with butter</h2>
                ... text of the section ...
                </body>
              </html>

参考リソース

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

検証

手順

セクションで構成されたコンテンツのあるページを調べる。
それぞれのセクションに見出しがあることを確認する。

期待される結果

2. の結果が真である。

G142: ズーム機能をサポートする一般に入手可能なユーザエージェントのあるウェブコンテンツ技術を使用する

適用 (対象)

ズーム機能を提供するユーザエージェントのある全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.4 (テキストのサイズ変更)
- クイックリファレンス 1.4.4 (テキストのサイズ変更)
- 達成基準 1.4.4 (テキストのサイズ変更)を理解する

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

G142 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、ズーム機能でテキストサイズを変更するユーザエージェントによってサポートされたウェブ技術を使用することによって、均一にコンテンツを拡大縮小できることを保障することである。

内容を均一 (すなわち、内容へズームする) に拡大縮小できるユーザエージェントによってサポートされたウェブコンテンツ技術で制作されたコンテンツは、この達成基準を満たす。この達成方法は、完全にユーザエージェントの機能に依存するため、さまざまなユーザエージェントを用いて検証することは重要である。

この達成方法では、ズーム機能を用いてもページ上の全ての空間的な関係が保持され、全ての機能が継続して利用可能である必要がある。

事例

Internet Explorer 7 と Opera 9は、HTML/CSS ページコンテンツを均一に拡大縮小するズーム機能を提供している。
利用者がテキストのサイズを変更できるように、Adobe Reader は PDF ページを均一に拡大縮小する拡大鏡機能を提供している。

訳注: ブラウザのズーム機能については、上記のブラウザだけでなく、ほとんどのモダンブラウザで提供されている。

(今のところ、なし。)

検証

手順

ユーザエージェントでコンテンツを表示する。
そのコンテンツを 200% にズームする。
全てのコンテンツ及び機能が利用可能かどうかを確認する。

期待される結果

3.の結果が真である。

G143: CAPTCHA の目的を説明するために、テキストによる代替を提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する
注記: この達成方法は、達成基準 1.1.1 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.1.1 を理解するを参照すること。

解説

この達成方法の目的は、非テキストコンテンツを特定するテキストによる代替を介して情報を提供することである。これは、CAPTCHA のテストが、ぼやけた画像又は音声ファイルで提示されるテキストを入力するよう利用者に求めることがしばしばあるためである。このテキストによる代替によって、利用者は、CAPTCHA がタスクの完了を要求するもので、またそれがどのようなタスクであるかを理解できるようになる。

CAPTCHA の代替版がある際には、テキストによる代替には、その代替版を見つける方法についての説明を含めるべきである。

事例

CAPTCHA のテストが、ぼやけた画像で表示されたテキストを入力するよう、利用者に求めている。そのテキストによる代替には、「画像に表示された言葉をタイプ入力してください」と書かれている。
CAPTCHA のテストが、音声ファイルで再生されるテキストを入力するよう、利用者に求めている。そのテキストによる代替には、「音声で聞こえる文字をタイプ入力してください」と書かれている。

G144: 異なるモダリティを用いて同じ目的を果たす、もう一つの CAPTCHA がウェブページに含まれていることを確認する

検証

手順

CAPTCHA を取り除く、非表示にする、又は覆い隠す。
CAPTCHA をテキストによる代替に置き換える。
テキストによる代替が CAPTCHA の目的を説明していることを確認する。

期待される結果

3. の結果が真である。

G144: 異なるモダリティを用いて同じ目的を果たす、もう一つの CAPTCHA がウェブページに含まれていることを確認する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する
注記: この達成方法は、達成基準 1.1.1 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.1.1 を理解するを参照すること。

解説

この達成方法の目的は、障害のある利用者が CAPTCHA のタスクを完了できないという事態を減らすことである。異なるモダリティを用いた代替の CAPTCHA を提供することによって、利用者がいずれかの CAPTCHA によりタスクを完了できる可能性が高まる。

事例

あるプロセスで次のステップに進むために利用者が完了しなければならない CAPTCHA のテストを含んだウェブページがある。ウェブページには、画像に表示されている言葉をタイプ入力する視覚的なタスク、及び音声ファイルで読み上げられる文字をタイプ入力する音声によるタスクの両方がある。聴覚に障害のある利用者は、音声 CAPTCHA をクリアすることはできないが、視覚的な CAPTCHA であればクリアすることが可能になる。
ブログのコメント記入フォームに視覚的な CAPTCHA が含まれていて、利用者がコメントを送信するには、この CAPTCHA をクリアしなければならない。視覚的な CAPTCHA のほかに、「2＋7 の答えは」と問うフォームで利用者が解答を記入するためのテキスト入力フィールドが用意された CAPTCHA もある。

G143: CAPTCHA の目的を説明するために、テキストによる代替を提供する

検証

手順

ウェブページにある各 CAPTCHA に対して:

ウェブページに、同じ目的を果たす、異なる感覚モダリティを用いたもう一つの CAPTCHA が含まれていることを確認する。

期待される結果

1. の結果が真である。

G145: テキスト (及び文字画像) とその背景の間に、少なくとも 3:1 のコントラスト比を確保する

適用 (対象)

あらゆるウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.3 (コントラスト (最低限) )
- クイックリファレンス 1.4.3 (コントラスト (最低限) )
- 達成基準 1.4.3 (コントラスト (最低限) )を理解する

解説

この達成方法の目的は、利用者が背景の上にあるテキストを読めるようにすることである。この達成方法は、18pt (太字ではない: 日本語の場合は 22pt) 以上と 14pt (太字: 日本語の場合は 18pt) 以上のテキストに対しては、少なくとも 3:1 以上のコントラスト比を要求している。

もし背景が無地の色 (または真っ黒、真っ白) の場合、各テキストの文字と背景との間に 3:1 のコントラスト比を持たせることで、大きなサイズのテキストのコントラスト比を維持することができる。

背景または文字が相対輝度において変化する (またはパターン化されている) 場合、たとえ背景全体とのコントラスト比を 3:1 で保持していなくとも、文字の周囲の背景又は陰影によって、文字と背景のコントラスト比を維持することができる。

コントラスト比は、背景の相対輝度がページをまたがって変化する時に、文字の相対輝度も変化させることによって維持されることもある。

事例

黒い背景を選ぶことによって、企業ロゴに合った明るい色の文字を使うことができる。
大きなサイズのテキストが大学のキャンパスの写真の上に書かれている。幅広いさまざまな色や暗さが写真に現れているため、テキストの下のエリアに白いもやをかけ、写真を強くかすませることで、一番暗い所でも写真の上に書かれている黒いテキストとの 3:1 のコントラスト比を維持するのに十分な明るさとしている。

参考リソース

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

訳注: 「Colour Contrast Analyser」は 2018 年現在、Firefox Add-ons から入手できない状態にある。

(今のところ、なし。)

検証

手順

以下の公式を用いて、各文字 (すべて同一ではない限り) の相対輝度を測る:
- 色の相対輝度 L = 0.2126 * R + 0.7152 * G + 0.0722 * B と定義されている。この場合の R, G 及び B は:
  - R_sRGB <= 0.03928 の場合: R = R_sRGB/12.92、それ以外の場合: R = ((R_sRGB+0.055)/1.055) ^ 2.4
  - G_sRGB <= 0.03928 の場合: G = G_sRGB/12.92、それ以外の場合: G = ((G_sRGB+0.055)/1.055) ^ 2.4
  - B_sRGB <= 0.03928 の場合: B = B_sRGB/12.92、それ以外の場合: B = ((B_sRGB+0.055)/1.055) ^ 2.4
  注記: また、R_sRGB, G_sRGB, 及び B_sRGB は以下のように定義される:
  - R_sRGB = R_8bit/255
  - G_sRGB = G_8bit/255
  - B_sRGB = B_8bit/255
  注記: "^"記号は指数演算子である。
注記: エイリアス文字では文字の端から 2 ピクセルの部分の相対輝度の値を使用する。
同じ公式を用いて、文字のすぐ隣の背景のピクセルの相対輝度を測る。
次の公式を用いて、コントラスト比を算出する。
- (L1 + 0.05) / (L2 + 0.05) ここで、
  - L1 は前景又は背景色の明るい方の相対輝度である。及び、
  - L2 は前景又は背景色の暗い方の相対輝度である。
コントラスト比が 3:1 以上である。

期待される結果

4.の結果が真である。

G146: リキッドレイアウトを使用する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.4 (テキストのサイズ変更)
- クイックリファレンス 1.4.4 (テキストのサイズ変更)
- 達成基準 1.4.4 (テキストのサイズ変更)を理解する
注記: この達成方法は、達成基準 1.4.4 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.4.4 を理解するを参照すること。
達成基準 1.4.8 (視覚的提示)
- クイックリファレンス 1.4.8 (視覚的提示)
- 達成基準 1.4.8 (視覚的提示)を理解する
注記: この達成方法は、達成基準 1.4.8 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.4.8 を理解するを参照すること。

解説

この達成方法の目的は、利用可能な水平方向のスペースに適合するレイアウト技術を使用することで水平方向のスクロールバーを導入することなくコンテンツの提示を可能にすることである。リキッドレイアウトは、テキストのサイズを変更するとともに、画面上にその領域を表示するために必要なリフローを行うようなレイアウト領域を定義する。したがって、厳格なレイアウトは異なるが、要素と読み上げ順序の関係は同じままである。これは、さまざまなデバイスやフォントサイズの好みの異なる利用者に適したデザインを作成するための効果的な方法である。

リキッドレイアウトの基本原則は次のとおりである。

レイアウト領域を、テキストに応じてサイズが変わるユニットを利用して定義する。つまり、テキストの拡大縮小と同じように、レイアウト領域が広まったり狭まったりする。
レイアウト領域を、フロートボックスを隣り合わせで横に並べたように配置する。つまり、パラグラフの中の各単語とほぼ同じような方法で、必要に応じて行送りされる。

複雑なリキッドレイアウトの実現には、入れ子にしたレイアウト領域、つまり大きな領域の中に部分ごとの複数の領域を入れ込む方法を利用する場合がある。単純なリキッドレイアウトであっても、テキストサイズの違いに関わらず見た目のよさを損なわないようにデザインを工夫する必要があるとはいえ、十分に計画したリキッドレイアウトは最も効果的なページデザインとなるだろう。

事例

事例 1: HTML と CSS での単純なリキッドレイアウト

以下は、リキッドレイアウトの実現に HTML と CSS を利用した、かなり単純な事例である。三つの列はテキストサイズが変わるのと同じようにサイズ調整される。もし全ての列を足した幅が、三つの列で利用できる幅の合計を超えてしまった場合、最後の列は前の列の横に置かれるのではなく、下に送られる。列に含まれるテキストの中で最も長い単語が列の幅におさまっている限り、フォントサイズを大きくすることができ、ブラウザの横スクロールバーへの影響はない。この事例では列の幅指定にパーセントを利用しており、「float」プロパティを利用して列をフロート領域として定義している。

コード例:


              <!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">
                <head>
                <meta http-equiv="content-type" content="text/html; charset=utf-8" />
                <title>Example of Basic Liquid Layout</title>
                <style type="text/css">
                .column
                {
                border-left: 1px solid green;
                padding-left:1%;
                float: left;
                width: 32%;
                }
                #footer
                {
                border-top: 1px solid green;
                clear: both;
                }
                </style>
                </head>
                <body>
                <h1>WCAG Example</h1>
                <h2>Text in Three Columns</h2>
                <div title="column one" class="column">
                <h3>Block 1</h3>
                <p> The objective of this technique is to be able to present content 
                without introducing horizontal scroll bars by using layout 
                techniques that adapt to the available horizontal space.
                </p>
                </div>
                <div title="column two" class="column">
                <h3>Block 2</h3>
                <p> This is a very simple example of a page layout that adapts as the
                text size changes.
                </p>
                </div>
                <div title="column three" class="column">
                <h3>Block 3</h3>
                <p> For techniques that support more complex page layouts, see the
                Resources listed below.
                </p>
                </div>
                <p id="footer">Footer text</p>
                </body>
                </html>

参考リソース

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

検証

手順

ユーザエージェントでコンテンツを表示する。
テキストサイズを 200% に拡大する。
水平方向のスクロールなしに、全てのコンテンツ及び機能が利用できるかどうかを確認する。

期待される結果

3. の結果が真である。

G148: 背景色及び文字色を指定せず、その初期設定を変更するウェブコンテンツ技術の機能を使用しない

適用 (対象)

テキストと背景の色が別々に指定されている、及びブラウザが初期設定の色を制御できるあらゆるウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、利用者が背景の上にあるテキストを読めるようにすることである。この達成方法では、コンテンツ制作者は単純にテキストの色と背景色を指定しないことで、コントラストに関する処置を行わない。その結果、両方の色はユーザエージェントによって完全に決定される。

視覚障害を持つ人々の中には、彼らが見づらい何色かを上書きするようユーザエージェントを設定している人がいる。この達成方法は、ユーザエージェントとウェブサイトがコンフリクトを起こし、結果として文字色と背景色が同じ色になってしまうことで、ブラウザや支援技術で独自の色設定をしている利用者にとって不可視の状態になるという場合を避けるためのものである。

事例

事例 1

コンテンツ制作者はテキストの色も背景も指定していない。CSS も使用していない。その結果、利用者は彼らにとって都合のよい色とコントラストを提供するブラウザの初期設定を利用可能となる。

参考リソース

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

訳注: 「Colour Contrast Analyser」は 2018 年現在、Firefox Add-ons から入手できない状態にある。

検証

手順

テキストの色を指定できる箇所全てを見る。
テキストの色が指定されていないことを確認する。
背景として用いられている背景色又は画像が指定されている箇所全てを見る。
背景として用いられている背景色又は画像が指定されていないことを確認する。

期待される結果

2. 及び 4. の結果が真である。

G149: フォーカスを受け取るときに、ユーザエージェントによって強調されるユーザインタフェースコンポーネントを使用する

適用 (対象)

ユーザエージェントによって提供されるフォーカスのハイライトを用いる全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.7 (フォーカスの可視化)
- クイックリファレンス 2.4.7 (フォーカスの可視化)
- 達成基準 2.4.7 (フォーカスの可視化)を理解する

解説

この達成方法の目的は、ユーザエージェントのサポートにより、利用者が、フォーカス可能なコンポーネントを視覚的に識別できるようにすることである。フォーカスを受け取った際に、何らかの方法で標準的なコンポーネントを強調することはユーザエージェントでは一般的である。UAAG のチェックポイント 10.2 "Highlight selection, content focus, enabled elements, visited links" を満たす場合、UAAG に適合したユーザエージェントでは標準的なコンポーネントは強調される。ユーザエージェントがサポートしている標準的なコントロールをウェブ制作者が使用すれば、利用者は、フォーカスの置かれている場所を標準的で予測可能な方法で知ることができる。

事例

HTML のテキスト入力フィールドがフォーカスを受け取ったとき、ブラウザーが、テキストフィールドの中の入力箇所に点滅する垂直なバーを表示する。
HTML のリンクがフォーカスを受け取ったとき、フォーカスを強調する長方形の点線で囲まれる。

参考リソース

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

User Agent Accessibility Guidelines 10.2: Highlight selection, content focus, enabled elements, visited links

検証

手順

ウェブページ上のフォーカス可能な各コンポーネントに対して:

そのコントロールにフォーカスを設定する。
何らかの方法でユーザエージェントがコントロールをハイライトしているかどうかを確認する。

期待される結果

2. の結果が真である。

G150: ライブの音声のみのコンテンツに対して、テキストベースの代替コンテンツを提供する

適用 (対象)

ライブの音声しか含まない情報を提示する全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 1.2.9 (音声のみ (ライブ) )
- クイックリファレンス 1.2.9 (音声のみ (ライブ) )
- 達成基準 1.2.9 (音声のみ (ライブ) )を理解する

解説

この達成方法の目的は、耳の聞こえない利用者がリアルタイムの音声の放送にアクセスできるようにすることである。間違いを修正する、聞きなおす、又は言葉が正しく再現できているかを誰かに確認する時間がほとんどないため、リアルタイムの代替物を制作することは困難である。また、音声の放送が非常に速く流れている場合は、情報を簡略化したり、言い換えたりすることも困難である。

リアルタイムのタイピングによるテキスト入力技術には、速記及び高速タイピングがある。復唱して音声認識入力する方法 (話を聞き取って、注意深く復唱し、復唱する話者の音声認識トレーニングをしたコンピュータで入力する) は、現在では電話伝送サービスに使用されており、将来的にはキャプション制作に使用されるかもしれない。いずれは修正機能付きの音声認識入力も可能になるだろう。

事例

ラジオ局でライブのスポーツイベントの代替コンテンツとして、ウェブベースのキャプションサービスを用いている。そのサービスでは、代替コンテンツはウェブページのビューポートに組み込まれて表示され、ストリーミング用の音声調節も付いている。

G9: ライブの同期したメディアに対してキャプションを作成する

検証

手順

テキストによる代替がリアルタイムで伝達されるように手順及びポリシーが整っている。
テキストによる代替が表示されるかどうかをランダムにチェックすると、手順及びポリシーが機能していることを確認する。

期待される結果

1. 及び 2. の結果が真である。

G151: 台本に従う場合に、準備された声明又は台本のテキストトランスクリプトへのリンクを提供する

適用 (対象)

ライブの音声しか含まない情報を提示する全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 1.2.9 (音声のみ (ライブ) )
- クイックリファレンス 1.2.9 (音声のみ (ライブ) )
- 達成基準 1.2.9 (音声のみ (ライブ) )を理解する

解説

この達成方法の目的は、トランスクリプト (書き起こしたテキスト) 又はライブの音声コンテンツが予め用意された台本に従っている場合は台本を提供することである。台本は予め用意されているので、ライブの書き起こしより正確で完全である。台本は音声の再生には同期しないこともあるが、この達成方法を用いるには、ライブの音声は台本から逸脱するべきではない。

この達成方法をもちいることによって、トランスクリプト又は台本へのリンクが提供され、WCAG 2.0 に適合する。そのトランスクリプト又は台本は、同じウェブページ上にあってもよいし、別の URI にあってもよい。

事例

フリンジシアター (小劇場) のグループによるライブのラジオ劇がウェブで放送されている。俳優は用意された台本に概ね従っており、演目のための予算も少ないので、プロデューサーは (劇作家の承諾を得て) HTML でその劇の台本へのリンクを設けた。
政府の一人がウェブ上で重要な政策のスピーチを行う。スピーチが始まると、スピーチのトランスクリプトがウェブサイト上から入手できるようになる。

参考リソース

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

検証

手順

台本又はトランスクリプトに直接遷移するリンクが存在するかどうかを確認する。
ライブの音声が台本に従っていることを確認する。
代替版が別のページにある場合、利用者がその版にアクセスできるリンクが設けられていることを確認する。

期待される結果

上記全ての結果が真である。

G152: (5 秒以内の) 数回のループ後に点滅を停止するように、アニメーション GIF を設定する

適用 (対象)

アニメーション GIF (GIF89a) をサポートするあらゆるウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.2 (一時停止、停止、非表示)
- クイックリファレンス 2.2.2 (一時停止、停止、非表示)
- 達成基準 2.2.2 (一時停止、停止、非表示)を理解する

解説

この達成方法の目的は、アニメーション GIF 画像が 5 秒以内に点滅を停止するようにすることである。アニメーション GIF 画像を制作する際には三つの側面があり、それらが作用しあって画像が点滅する (あるいは動く) 時間を決定している:

アニメーション画像に含まれるフレーム数: これらは連続するアニメーションの中では別々の画像である
フレームレート: それぞれの画像を表示する時間
繰り返しの回数: アニメーション全体を再生させる回数

一番単純な場合では、アニメーションの再生時間は、フレーム数×フレームレート×繰り返し回数である。例えば、2 フレームでフレームレートが 0.5 秒、繰り返しが 3 回の単純な点滅する画像では、再生時間は (2×0.5×3) 秒、即ち、ちょうど 3 秒である。

多くのアニメーション GIF 画像のフレームレートは一定である。すなわち、個々のフレームが表示される時間は同じである。しかし、フレームに対して異なるフレームレートを設定することもでき、特定のフレームのみ他より長く表示させることが可能である。この場合、アニメーションの再生時間は、フレームレートの合計×繰り返し回数である。例えば、2 フレームで、1 枚目が 0.75 秒表示、2 枚目が 0.25 秒表示され、繰り返しが 3 回の単純な画像では、再生時間は ((0.75+0.25)×3) 秒、同様にちょうど 3 秒となる。

5 秒以内に画像の点滅を終了させるためには、三つの変数のうちのいずれかを調整しなければならない。最も一般的には、繰り返しの回数を 5 秒÷フレーム数×フレームレート (又は 5 秒÷フレームレートの合計) に設定し、5 秒以内に画像を終了させるために、最も近い整数になるようにこの数字の端数を切り捨てる。一つ上の整数に切り上げてはならない。

繰り返しが 1 回で 5 秒を超える場合は、別の要素のうちの一つを調整しなければならない。画像の中のフレーム数を減らす、又はフレームレートを増やす。フレームレートを増やす場合は、変更後の画像が一般閃光閾値又は赤色閃光閾値を超えないという要求事項に不合格にならないように留意すること。これは大きな画像では特に重要であるので注意すること。

事例

単純な点滅する画像: フレーム数が 2、フレームレートが 0.5 秒で繰り返しが 3 回の画像がある。アニメーションの再生時間は (2×0.5×3) 秒、すなわち 3 秒ちょうどとなり、したがって達成基準の要件を満たす。

検証

手順

アニメーション GIF 及びそのアニメーションの再生時間をを表示する。
別の方法として、画像編集ソフトを使用してフレーム数、フレームレート及び繰り返し回数を確認する。フレーム数×フレームレート×繰り返し回数を計算する。フレームレートが一定でない場合、フレームレートの合計×繰り返し回数を計算する。
いずれの方法を用いても、アニメーションの再生時間が 5 秒以内である。

期待される結果

3. の結果が真である。

G153: テキストを読みやすくする

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.5 (読解レベル)
- クイックリファレンス 3.1.5 (読解レベル)
- 達成基準 3.1.5 (読解レベル)を理解する

解説

この達成方法の目的は、ウェブページ上のテキストを読むのが難しくないようにすることである。単語や文を解読することが困難になるような障害のある利用者は、複雑なテキストを読んで理解するのを苦手とすることが多い。そのテキストが前期中等教育レベルを超えた読解能力を必要としないならば、補足や代替版は必要ない。

テキストの複雑さを軽減する方法:

訳注: 以下は英語における留意点であると考えられ、日本語の場合に全てが当てはまるとは限らない。

段落ごとに一つのトピックまたはサブトピックのみを展開する。
コンテンツの目的に矛盾しない範囲でもっとも単純な構文を用いる。たとえば、英語のもっとも単純な構文は「John hit the ball」、「The Web site conforms to WCAG 2.0」のように「主語、動詞、目的語」からなる。
文の長さは、前期中等教育レベルで典型的に許される範囲とする。(注記: 英語では 25 ワードである)
長い文は二つに分割することを検討する。
一つの文に三つ以上の接続詞を用いないようにする。
テキスト中のフレーズ、文、段落、セクション間の論理的関係を明確にする。
一般の人にとって意味が明らかでないような専門的な職業語や俗語等の言い回しを避ける。
長い又は馴染みのない言い回しは、より短く一般的なものに置き換える。
取り除いても文章の意味が変わらないような冗長な単語を取り除く。
単独の名詞または短い名詞句を使用する。
文の意味を変えずにより広く使われる言い回しに置き換えられるような単語やフレーズを取り除く。
いくつもの単語やフレーズからなる複数の項目を、コンマで区切って一つの段落内に並べることは避け、番号なし/番号付きリストを使用する。
代名詞による参照や文中の他の箇所への参照は明確なものにする。
英語および他の一部の欧米系言語で書かれる文書では、受動態を使う特別な理由がない限り、能動態を用いる。たいていの場合、能動態の文章は受動態よりも短く、理解しやすい。
動詞の時制に一貫性を持たせる。
名前やラベルに一貫性を持たせる。

事例

ウェブアプリケーションのヘルプページは、前期中等教育レベルよりも高度ではない言葉づかいで書かれている。

検証

手順

テキストの読みやすさを測定する。
そのテキストが要求する読解能力が、前期中等教育レベルを超えていない。

期待される結果

2. の結果が真である。

G155: 送信ボタンに加えてチェックボックスを提供する

適用 (対象)

あらゆるウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、利用者が自身の入力した内容を確認し、送信の準備ができたことを示すために選択しなければならないチェックボックスを提供することである。これは、後で入力エラーが発見されてもやり直しができない、または実行の結果データが削除されるような性質の処理においては重要である。コンテンツ制作者は、ページが読み込まれた時には選択されていないチェックボックスを配置し、「入力内容に間違いはなく、送信準備ができました」、あるいは「このデータの削除に同意します」といったラベルを付加する。このチェックボックスは、利用者が送信の過程で気づきやすいように、送信ボタンの近くに配置するべきである。そのフォームが送信された時にチェックボックスが選択されていない場合は、入力を受け付けず、利用者に対して入力内容を確認の上、チェックボックスを選択し、再送信するように促す。チェックボックスが選択されているときだけ、送信された内容を受け付け、処理を行う。

このチェックボックスを配置することで、フォームを誤って送信してしまった場合の影響を抑制すると同時に、利用者に対して入力内容が正確であることを確認するように促すことができる。この方法は、単に送信ボタンに「入力内容に誤りがなければ送信」というようなラベルを付加するよりも安全な方法である。送信ボタンとは別のコントロールとしてチェックボックスを提供することで、処理を続行するために利用者はチェックボックスの選択と送信ボタンの動作の両方をしなければならず、結果として入力内容をサイド確認することにつながる。したがって、これは送信内容を確定する前に、入力内容を見直し、正確さを確認し、訂正するための仕組みである。

注記: 利用者がチェックボックスを選択せずに送信した場合、再送信のためのフォームで、これまでに入力した情報を再入力する必要がないようにしなければならない。

事例

あるオンライン銀行サービスでは、異なる通貨の口座間で資金を振り替えることが可能である。為替レートは常に変化しているため、取引が実行された後に利用者が入力に誤りを発見した場合に、その資金を同じレートで再両替できない。「振り替え元口座」、「振り替え先口座」、「金額」の欄に加えて、「振替金額が正しいことを確認しました」というラベルのチェックボックスがある。利用者がフォームを送信するときにこのチェックボックスが選択されていない場合は、取引は実行されず、利用者に通知される。チェックボックスが選択されている場合は、(取り消しできない) 取引が実行される。
オンラインで支払いを可能にするシステムでは、支払いを可能にするために利用者の銀行口座情報を保持している。新しい口座に関する情報を入力し、その口座がその利用者のものであることを証明するためには、細かい手順を踏まなければならない。古い口座を削除する機能があるが、誤って口座を削除した場合、その口座を復活させるのは難しいし、それまでのその口座に対する処理の記録は失われてしまう。そこで、口座の削除を行うことができるページには、「この口座の削除を希望します」というラベルを付加したチェックボックスが配置されている。利用者がこのフォームを送信したときにこのチェックボックスが選択されていない場合は、口座の削除は行わず、利用者に対してはエラーメッセージを表示する。このチェックボックスが選択されているときのみ、口座の削除を実行する。
あるショッピングサイトの精算フォームには、注文、配送、及び請求情報を収集するフォームが含まれている。フォームを送信した後に、利用者は、送信した情報が確認のために要約されたページに移動する。要約の下に、「このデータが正しいことを確認しました」というラベルの付いたチェックボックスが表示される。取引を完了させるには、利用者がチェックボックスにチェックを入れて「注文完了」ボタンを有効にしなければならない。

検証

手順

取り消しできない処理が発生する利用者の入力ページの場合:

送信ボタンに加えて、入力又は操作に対する利用者の確認を示すチェックボックスが提供されていることを確認する。
フォームが送信されたときにチェックボックスが選択されていない場合は、入力は受け付けられず、利用者に対して入力内容の確認をした上で、チェックボックスを選択し、再送信するようになっていることを確認する。

期待される結果

1. 及び 2. の結果が真である。

G156: テキストのブロックの前景及び背景を変更できる、一般に入手可能なユーザエージェントが備えるウェブコンテンツ技術を使用する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

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

G156 に関するユーザエージェントサポートノートを参照のこと。

解説

認知障害のある利用者は、ウェブページのコンテンツをうまく理解するために、前景のテキストと背景を特定の色の組み合わせを必要としていることがある。一般に利用されるブラウザの大部分が、ブラウザ内部の機能として、色設定を変更するオプションを提供している。この機能によって、コンテンツ制作者が指定した前景色や背景色を、利用者が選択した色で上書きできる。

この達成基準を満たすためには、コンテンツ制作者はこのようなコントロールを備えるブラウザでウェブページが利用できるようにデザインし、この機能を無効にするような実装を行なってはならない。

ページ上の全てのテキストの前景色と背景色を上書きすると、ページのグループ化や組織化に関する視覚的な手がかりが失われ、かえって理解や利用が困難になる恐れがある。ページ上の各領域の境界を示すのに背景色を用いている場合、この達成方法が適切ではない可能性がある。背景色をページ上の各領域の境界を示すのに用いているならば、「C23: メインコンテンツのテキスト及び背景の色を指定せず、バナー、機能及びナビゲーションなどのような補助的なコンテンツのテキスト及び背景の色を CSS で指定する (CSS) 」に基づき、ページの視覚的な構造は保ちつつ、利用者が主要なテキストの色をコントロールできるようにするとよい。

事例

前景色と背景色の指定のために、HTML と CSS を用いてデザインしているウェブページがある。利用者は Internet Explorer 7 で自分の望む色に設定し、選択した前景色と背景色でコンテンツを見ることができる。
HTML と CSS を用いてデザインしているウェブページがある。さまざまなブラウザでどのように色を設定するかを説明したページへのリンクを設置している。

訳注: Firefox 及び Chrome では、例えば Stylus という拡張機能を追加することで、ユーザスタイルシートにより好みの前景色と背景色を指定できる。

参考リソース

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

検証

手順

HTML コンテンツの色を利用者が変更できるブラウザで、ウェブページを開く。
ブラウザ設定で、コンテンツに指定された色とは異なる前景色及び背景色に変更する。
ページに戻ると、ブラウザで設定した別の前景色及び背景色が、コンテンツに指定された色を上書きしていることを確認する。

期待される結果

3. の結果が真である。

G157: ライブの音声キャプションサービスをウェブページに組み込む

適用 (対象)

ライブの音声しか含まない情報を提示する全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 1.2.9 (音声のみ (ライブ) )
- クイックリファレンス 1.2.9 (音声のみ (ライブ) )
- 達成基準 1.2.9 (音声のみ (ライブ) )を理解する

解説

この達成方法の目的は、ライブの音声コンテンツのテキスト版を提供するために、リアルタイムのキャプションサービスを用いることである。このようなサービスは、何が話されているかを聞き取り、専用キーボードによりわずかな遅れでテキスト入力する訓練を受けた人間のオペレーターによって行われる。彼らは非常に忠実にライブのイベントを捉えることができ、そのイベントを理解する上で重要な発話以外の音声についても注記を入れることができる。キャプションのテキストを含むビューポートは、ライブの音声コンテンツと同一のウェブページ上で利用できる。

事例

インターネットラジオ局で、ウェブページ上にニュースサービスのためのビューポートがある。ライブのニュースのレポート、特に緊急レポートの場合、リアルタイムのキャプションサービスによりテキストが書き起こされてビューポートに表示される。
会議又はスクリーンシェアリングサービスに、口頭発表のリアルタイムの書き起こしを流すウィンドウがある。これは、遠隔リレー式音声電話会議キャプションサービスを予め手配しておくことで実現している。ライブのテキスト用に別のウィンドウを使用すると重大なユーザビリティ上の障害となりうるので、オンラインウェブ会議又はスクリーンシェアリングサービスではこのような使われ方をすることを想定してデザインする必要がある。
定例の音声会議では、順番に発言できるように挙手機能ユーティリティを使用している。オンラインリレー式音声電話会議キャプションサービスと共にこの製品を利用しやすくするために、発言順のユーティリティは、狭いビューポートの中で全ての機能を操作できるようにデザインされている。より高度な利用のために、ウェブサイトは 1 ページの中に両方のビューポートを表示するように制作されている。

参考リソース

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

Real-time Captioning
Captioned Text (provider for relay conference captioning)
Wikipedia entry for CART (variously Computer Assisted Real-time Captioning or Communication Access Real-time Translation)
Communication Access Information Center
Web conferencing products with integrated support for captioning viewport

検証

手順

ライブの音声コンテンツと関連付けられたビューポートがウェブページ上にあることを確認する。
ライブの音声コンテンツのテキストが、30 秒未満の遅れでビューポートに表示されることを確認する。

期待される結果

上記全ての結果が真である。

G158: 音声のみの時間依存メディアに対する代替コンテンツを提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.2.1 (音声のみ及び映像のみ (収録済) )
- クイックリファレンス 1.2.1 (音声のみ及び映像のみ (収録済) )
- 達成基準 1.2.1 (音声のみ及び映像のみ (収録済) )を理解する

解説

この達成方法の目的は、音声しか含まない提示で情報を提示するためのアクセシブルな代替方法を提供することである。

音声しか含まない提示においては、会話や音 (自然なものと人工的なものの両方) を含め、情報はさまざまな方法で提示される。同じ情報をアクセシブルな形式で提示するために、この達成方法では、収録済の音声しか含まないコンテンツと同じストーリーを伝えて同じ情報を提示するドキュメントを作成する。この達成方法において、そのドキュメントはコンテンツの長い説明としての役割を果たし、重要な会話内容のすべてとストーリーの一部である背景音の説明を含んでいる。

音声しか含まないコンテンツを制作する際に台本を用いている場合には、それを手始めにすることができる。しかし、制作及び編集過程において、コンテンツの内容が台本からいくぶん変わってしまうことがよくある。この達成方法で台本を用いる際は、もともとの台本を音声の提示の最終版の会話内容及び実際の内容に合わせて修正することになる。

事例

ソフトウェアの最新のリリースにおける新機能の説明をしているポッドキャストがある。二人の話者が、新機能と更新された機能について話をしながら、どのように使うのかを説明している。話者の一人は、収録前に議論のアウトラインを整理するために用意した質問のリストを使っている。そして収録終了後、そのアウトラインを編集して、会話内容に合わせて言葉を補うなどする。そうして出来上がったトランスクリプトは、音声しか含まないファイルと一緒に、話者のウェブサイトで公開されている。音声しか含まないコンテンツを特定するテキストによる代替には、「エピソード 42: Zap バージョン 12 (テキストのトランスクリプトあり)」と書かれていて、そのトランスクリプトへのリンクが、音声しか含まないコンテンツのすぐ後に提供されている。

参考リソース

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

検証

手順

時間依存メディアに対する代替コンテンツを参照しながら、音声しか含まないコンテンツを閲覧する。
トランスクリプト内の会話内容が、音声しか含まない提示に表示されている会話内容及び情報と一致することを確認する。
音声に複数の話者がいる場合、すべての会話内容に対してトランスクリプトで話者が誰なのかを特定していることを確認する。
次のうち少なくとも一つが真であることを確認する:
1. トランスクリプト自体が、音声しか含まないコンテンツに対するテキストによる代替からプログラムによる解釈が可能である。
2. トランスクリプトが、音声しか含まないコンテンツに対するプログラムによる解釈がされるテキストによる代替から参照されている。
代替版が別ページにある場合、利用者が他の版へアクセスできるリンクが使用できることを確認する。

期待される結果

上記の手順全ての結果が真である。

G159: 映像のみの時間依存メディアに対する代替コンテンツを提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、映像しか含まない提示で提示する情報に対して、アクセシブルな代替コンテンツを提供することである。

映像しか含まない提示においては、アニメーション、テキスト又はグラフィック、また状況及び背景、人物や動物の動き及び表情などを含め、情報はさまざまな方法で提示される。同じ情報をアクセシブルな形式で提示するために、この達成方法では、収録済の映像しか含まないコンテンツと同じストーリーを伝えて同じ情報を提示するドキュメントを作成する。この達成方法において、そのドキュメントはコンテンツの長い説明としての役割を果たし、重要な情報のすべてと提示の一部である風景、動き、表情などの説明を含んでいる。

映像しか含まないコンテンツを制作する初めの段階で台本を用いている場合には、それを手始めにすることができる。しかし、制作及び編集過程において、コンテンツの内容が台本からいくぶん変わってしまうことがよくある。この達成方法で台本を用いる際は、もともとの台本を映像しか含まないプレゼンテーションの最終版の内容に合わせて修正する必要がある。

事例

木工品の組み立て方を紹介するアニメーションがある。音声はないが、アニメーションにはプロセス中の各ステップの順番を示す番号があり、矢印と該当箇所の拡大図によってどのように組み立てていくのかが示されている。あわせて、正しく組み立てなかった場合にはどうなるのかを示す短いアニメーションも提供されている。映像しか含まないコンテンツを特定するテキストによる代替には、「パン入れの組み立て方の映像 (テキストによる説明あり)」と書かれていて、映像のテキストによる説明では、その映像にある各ステップの完全なテキストによる説明が提供されている。

参考リソース

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

検証

手順

時間依存メディアに対する代替コンテンツを参照しながら、映像しか含まないコンテンツを閲覧する。
トランスクリプト内の情報によって、映像しか含まない提示と同じ情報が含まれていることを確認する。
映像に複数の登場人物がいる場合、トランスクリプトで説明されているそれぞれの動きに関連付けられるものが、どの登場人物によるものかが特定されることを確認する。
次のうち少なくとも一つが真である:
1. トランスクリプト自体が、映像しか含まないコンテンツに対するテキストによる代替からプログラムによる解釈が可能である。
2. トランスクリプトが、映像しか含まないコンテンツに対するプログラムによる解釈がされるテキストによる代替から参照されている。
代替版が別ページにある場合、利用者が他の版にアクセスできるリンクが利用可能できることを確認する。

期待される結果

上記の手順全ての結果が真である。

G160: コンテンツを利用するために理解が不可欠な情報、アイデア及びプロセスの手話バージョンを提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.5 (読解レベル)
- クイックリファレンス 3.1.5 (読解レベル)
- 達成基準 3.1.5 (読解レベル)を理解する

解説

聴覚障害や認知障害のある利用者の中には、手話を第一言語としている人がいる。そのような利用者にとっては、文語バージョンよりもページの手話バージョンのほうが理解しやすい可能性がある。この達成方法の目的は、概念やプロセスが記述された難しいテキストについて、手話利用者の理解するのを助ける手話バージョンを提供することである。手話コンテンツはそのテキストに追加で提供する。

手話バージョンは補足コンテンツであるため (また、手話はコンテンツを音声で読み上げる目的のものではないため)、主要なコンテンツとは別の部分で見られる状態にすべきだが、必ずしも同期させる必要はない。同期が有用な場合があるとしても、必須ではない。

手話バージョンをコンテンツの別の部分で利用可能にするために、ビデオをページに直接埋め込んだり、ビデオプレーヤーを別ウィンドウで起動するリンクを含めてもよい。ビデオ表示用の別ページへのリンクによって、手話バージョンを提供することもできる。

手話は、手のひら、腕、肩、頭、顔、唇、舌を使って伝える、3 次元の視覚言語である。何が示されているのかを受け手が正しく理解するために、ビデオでは完璧な手話を録画しなければならない。一般的に、手話通訳者は見切れ (ビデオの外に手が出てしまうこと) が発生しない範囲で、できるだけカメラに近づいて手話を行なう。

手話通訳者の見つけ方については、後述の参考リソースの部分に載っている。

訳注: ただし、主に英語圏での情報である。

訳注: 注記 2 に記載されている達成方法はまだ文書化されていない。

事例

あるウェブサイトでは、サポート部門への連絡方法や質問の送信方法を、テキストと同じく手話ビデオでも提供している。
あるウェブアプリケーションでは、ヘルプページをテキストと同じく手話でも提供している。
ある会社のウェブサイトでは、各製品の技術情報を説明した手話ビデオを提供している。
ある宗教団体のウェブサイトは、複数の言語で利用できるようにしてあり、その中にアメリカの手話も含めてある。

参考リソース

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

「手話 (収録済) - 達成基準 1.2.6 を理解する」の関連リソースも参照すること。

検証

手順

コンテンツを利用するために理解しなければならないアイデア又はプロセスを説明しているテキストを特定する。
コンテンツの中で、又は、コンテンツ内のリンクを通じて、テキストの補足となる手話が利用できることを確認する。
手話による補足が、テキストで説明している概念又はプロセスを示していることを確認する。

期待される結果

2. 及び 3. の結果が真である。

G161: 利用者がコンテンツを見つけるのを手助けするために検索機能を提供する

適用 (対象)

フォームを含む全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.5 (複数の手段)
- クイックリファレンス 2.4.5 (複数の手段)
- 達成基準 2.4.5 (複数の手段)を理解する

解説

あなたのウェブページを探す検索機能を提供するのは、コンテンツを見つける方法を利用者に提供するデザインの戦略である。利用者は、ウェブサイトの構造を理解したり、サイト内を見て回ったりする必要なく、特定の単語又は句で検索することでコンテンツの場所を特定することができる。これは、特に大きいサイトで、より迅速に又はより簡単にコンテンツを見つける方法である。

いくつかの検索企業は、彼らの検索アプリケーションの無償利用をサイトに提供している。検索エンジンはあなた自身のサーバーにインストールして利用できる。いくつかのウェブホスティング企業は、顧客がウェブページに含めることができる検索スクリプトを提供している。また、ほとんどのサービスが、より高度な特徴を持つそれらツールの有償バージョンを提供している。

用語をスペルチェックし、用語の異なった語尾を含み (ステミング)、異なった用語の使用 (同義語) を考慮する検索機能を実装すると、検索機能のアクセシビリティはさらに増すだろう。

検索の機能性は、普通は検索ワードのためのテキストフィールド及び検索を開始するためのボタンを含むウェブページの単純なフォーム、又は検索フォームを含むページへのリンクを追加することによって、高めることができる。もちろん、検索フォーム自体もアクセシブルでなければならない。

外部検索の検索エンジンの結果を最適化するのに使用され、また内部検索エンジンもサポートしており、それらをより効果的にする達成方法: キーワード、META タグ、およびアクセシブルなナビゲーション構造を使用する。検索サイトは、検索のために最適化されたコンテンツをどう作成するかのガイダンスを提供している。例えば、Google Webmaster Guidelines、及び Yahoo! Search Content Quality Guidelines である。

事例

事例 1: ショッピングサイト

あるショッピングサイトは、商品を、婦人服、紳士服、こども服といったいろいろなカテゴリーに分かれて構成されている。これらには、上着、ズボン、靴、アクセサリーといった小分類がある。また、各ページは検索フォームを含んでいて、利用者は、商品を見つけるために商品分類をたどって見ていくよりもむしろ、商品番号又は商品の特徴を検索フィールドに入力することにより、その商品に直接行くことができる。

事例 2: ヘルプセンター

あるヘルプセンターは会社の商品に関する何千ページものヘルプ情報を含んでいる。検索フォームにより、利用者は検索ワードを含む記事を見つけるためにヘルプセンターのページを検索できる。

参考リソース

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

検証

手順

ウェブページに検索フォーム又は検索ページへのリンクがあることを確認する。
一連のウェブページにある検索フォームにテキストを入力する。
検索を実行する。
利用者が検索ワードを含むページに辿り着くことを確認する。
利用者が検索ワードを含むページへのリンクのリストを含むページに辿り着くことを確認する。

期待される結果

1.の結果が真であり、4.又は 5.のいずれかの結果が真である。

G162: 関係性を最大限に予測できるようにするためにラベルを配置する

適用 (対象)

フォームをサポートするウェブコンテンツ技術全て

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する
達成基準 3.3.2 (ラベル又は説明)
- クイックリファレンス 3.3.2 (ラベル又は説明)
- 達成基準 3.3.2 (ラベル又は説明)を理解する
注記: この達成方法は、達成基準 3.3.2 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 3.3.2 を理解するを参照すること。

解説

フォームのフィールドに対するラベルを、視覚的に利用者が予想しやすい位置に置くと、複雑なフォームを理解したり、特定のフィールドを見つけるのが容易になる。ほとんどのフィールドに対するラベルは、そのフィールドの直前、すなわち、書字方向が左から右の言語の場合、そのフィールドの左か上に、書字方向が右から左の言語の場合、そのフィールドの右か上に置かれる。ラジオボタン及びチェックボックスのためのラベルはそのフィールドの後に置かれる。

これらの配置は自明である。フィールド、ラジオボタン、及びチェックボックスのラベルを置く一般的な (そのために最も予測できる) 位置だからである。

入力フィールドはさまざまな長さになることがあるため、ラベルはフィールドの前に置かれる。フィールドの前にそれらを置くことでラベルを整列させることができる。また、ラベルがフィールドの直前にあるため、画面拡大ツール使用時でもラベルの場所を見つけることが容易になり、また、(フィールドの始まりが縦に整列しているとき) 縦の列の中でも見つけることができる。最後に、フィールドにデータが入力されているならば、ラベルを読んでから内容を読むほうが、逆の場合よりもデータを理解したりチェックすることが容易になる。

チェックボックス及びラジオボタンは一定の幅を持っているが、それらのラベルは往々にしてそうではない。チェックボックス又はラジオボタンを最初に置くことで、ボタンとラベルの両方を縦に整列させることができる。

事例

事例 1: テキストフィールドの上側のラベル

すぐ上にラベルが配置された二つのテキストフィールド

事例 2: テキストフィールドの左側のラベル

すぐ左側にラベルが配置されたふたつのフィールド.

事例 3: ラジオボタンの右側のラベル

ラジオボタンの右側にラベルが配置されたふたつのラジオボタンを含むフォームのコントロールのグループ

参考リソース

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

検証

手順

ウェブページの各フォームのフィールドに対して:

フォームのフィールドに目に見えるラベルがあることを確認する。
フォームのフィールドがチェックボックス又はラジオボタンである場合、ラベルがそのフィールドの直後にあることを確認する。
フォームのフィールドがチェックボックス又はラジオボタンでない場合、ラベルがそのフィールドの直前にあることを確認する。

期待される結果

全ての結果が真である。

G163: オフにすることが可能な標準的な発音区別符号を使用する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.6 (発音)
- クイックリファレンス 3.1.6 (発音)
- 達成基準 3.1.6 (発音)を理解する

解説

この達成方法の目的は、標準的な発音区別符号をオンにしたりオフにできるメカニズムを利用者に提供することである。

単語の発音を正しく示したり、単語同士の区別に役立つように、多くの言語で発音区別符号が利用されている。一部の言語は、母音、重子音、母音や子音の欠落を示したり、他の目的のために発音区別符号を用いている。発音区別符号がなくてもテキストを読むことはできるが、発音区別符号の追加によって読解可能性 (リーダビリティ: Readability) を改善できる。

事例

事例 1

あるハワイ語で書かれたウェブページには、初期状態で発音区別符号が表示されているが、次のような発音区別符号の表示レベルを利用者が選択できるリンクが提供されている:

発音区別符号を表示しない
ʻokina (オキナ) の記号 (‘) は表示するが、長音記号は表示しない
全ての発音区別符号を表示する

訪問者が好みのレベルを選択すれば、その設定はセッションクッキーに保存される。同じセッションの間、後に見る全てのページはクッキーにアクセスをしつづけ、選択したレベルに合わせて発音区別符号が表示されたり非表示になる。

サーバーサイドでは、コンテンツには全ての発音区別符号が含まれている。訪問者が発音区別符号を少なくするか全くない選択肢を選べば、サーバーサイドで設定の通りに発音区別符号を置き換えたり取り除いてからページを表示する。

Hawaiian language online がその例である。

検証

手順

意味の区別のために発音区別符号を利用する自然言語で作った、あらゆるウェブページについて:

コンテンツの初期状態で発音区別符号を用いていることを確認する。
発音区別符号をオンにしたりオフにできるメカニズムがあることを確認する。
発音区別符号をオフにするメカニズムによって、発音区別符号が実際に非表示になることを確認する。
発音区別符号をオンにするメカニズムによって、発音区別符号が実際に表示されることを確認する。

期待される結果

1. から 4. の全ての結果が真である。

G164: オンラインリクエスト後に、利用者がそのリクエスト (又はトランザクション) を修正又はキャンセルできる一定の時間を提供する

適用 (対象)

フォームを提供する全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、注文を変更又はキャンセルできる猶予期間を提供することによって、利用者が誤った注文をしてしまった際にその内容を変更又はキャンセルできるようにすることである。一般的には、契約又は注文は法的な義務であり、キャンセルすることができない。しかしながら、ウェブサイトにおいては、この機能を提供し、利用者が注文内容を間違えてしまった際には、注文を変更又はキャンセルできるようにすることが可能である。

ウェブコンテンツでは、フォームを送信した後、キャンセル可能期間がどのくらいなのか、及びどのような手続きで注文をキャンセルするかを利用者に伝える必要がある。注文をキャセルする手続きがオンラインでは利用できない場合もあり得る。例えば、ウェブページ上に記載された住所宛に書面による通知が必要な場合である。

フォームを送信した後に、利用者にキャンセル可能期間の長さ及び、注文キャンセルの手続き方法を伝える。注文キャンセルの手続き方法を、キャンセル可能期間と同時に伝えることは、他のメカニズムを使えない利用者に必要で、最善の方法といえる。しかし、必要であれば、複合的な障害に対するアクセシビリティを担保できる場合に限り、他のメカニズムや他のメカニズムとの組み合わせでキャンセル手続きの方法を提供してもよい。その場合は、利用者にフォームを送信する前にオンラインでの注文はキャンセルができないことを警告する。

事例

事例 1: オンラインショッピング

オンラインショッピングのウェブサイトで、24 時間以内であれば利用者が購入をキャンセルできるようにしている。そのウェブサイトでは彼らの方針を説明しており、電子メールで利用者に送られる注文確認書の方針の要約も含まれている。24 時間以降は購入した物は利用者宛に発送され、キャンセルすることはできない。

事例 2: カスタムオーダー

あるウェブサイトでオーダーメイドのスポーツジャケットを販売している。顧客は生地を選び、身体の寸法を仕立て店に送る。ウェブサイトは注文の変更やキャンセルに対して 3 日の猶予を与えている。その顧客の寸法に合わせて生地が裁断されると、注文の変更又はキャンセルはできなくなる。そして、会社の方針がウェブサイト上で説明されている。

検証

手順

注文のキャンセル又は変更するための期間についてウェブページ上に記述があることを確認する。
注文のキャンセル又は変更するための手続きについてウェブページ上に記述があることを確認する。

期待される結果

1.及び 2.の結果が真である。

G165: 視認性の高いデフォルトのフォーカスインジケータが引き継がれるように、プラットフォームデフォルトのフォーカスインジケータを使用する

適用 (対象)

フォーカス可能な要素を提供する全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.7 (フォーカスの可視化)
- クイックリファレンス 2.4.7 (フォーカスの可視化)
- 達成基準 2.4.7 (フォーカスの可視化)を理解する

解説

OS には標準のフォーカス表示があり、多くのユーザエージェントで利用可能となっている。フォーカスインジケータのデフォルトのレンダリングは常に視認性に優れているわけではなく、ある背景では見づらいことがある。しかし、多くのプラットフォームでは、利用者がフォーカスインジケータのレンダリングのカスタマイズをすることができる。支援技術では、標準のフォーカスインジケータの外観を変更することもできる。コンテンツ制作者が標準のフォーカスインジケータを使用する場合、システム全体に対する見え方の設定はウェブページに引き継がれる。例えば、利用者の操作に反応してページの一部分を色付けするといったコンテンツ制作者独自のフォーカスインジケータを表示させる場合、このような設定は引継がれず、通常、支援技術はコンテンツ制作者独自のフォーカスインジケータを見つけることはできない。

事例

事例 1

Microsoft Windows のデフォルトのフォーカスインジケータは、フォーカスが当たっている要素の回りに 1 ピクセルの黒い点線で表示される。暗い背景のページ上では、これは非常に見づらくなる。そのページの制作者がデフォルトを使用し、利用者は Windows 上で明るい色にカスタマイズする。

事例 2

HTML において、フォーム要素とリンクにはデフォルトでフォーカスが当たるようになっている。さらに、tabindex の属性値が 0 以上のあらゆる要素はフォーカスを受け取る。フォーカスが当たっている要素はどちらのタイプの場合でも、システムのフォーカスインジケータを使用し、フォーカスインジケータのスタイルについてのプラットフォームの変更を検知する。

検証

手順

フォーカスインジケータの外観をカスタマイズするには、プラットフォームの機能を使用する。
フォーカスの移動順序に注意しながら、ページ内をタブキーで移動する。
各コントロールでフォーカスインジケータが視覚的に認識可能であることを確認する。

期待される結果

3.の結果が真である。

G166: 重要な映像コンテンツを説明する音声を提供する

適用 (対象)

映像コンテンツを実装できる全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 1.2.1 (音声のみ及び映像のみ (収録済) )
- クイックリファレンス 1.2.1 (音声のみ及び映像のみ (収録済) )
- 達成基準 1.2.1 (音声のみ及び映像のみ (収録済) )を理解する

解説

映像しか含まないコンテンツは、全盲の利用者及びロービジョンの利用者にとってはアクセシブルではない。そのため、これらの利用者が音声による代替コンテンツを利用できることが重要である。その一つの方法として、映像に含まれている情報を説明する音声トラックを提供する方法がある。この音声は、例えば MP3 のように、インターネット上で一般的に使われている音声フォーマットである必要がある。

事例

事例 1

ウェブページに、宇宙船の火星着陸シーンの映像しか含まない提示へのリンクがある。そして、この映像へのリンクは、宇宙船の写真である。この映像を説明する音声ファイルへのリンクが、映像の近くにある。これは、次の HTML コード例のようになるだろう。

コード例:


              <a href="../video/marslanding.mp4"><img src="../images/spaceship.jpg" 
                alt="Mars landing, video-only" width="193" height="255"/></a>
                <br />
                <a href="Mars_landing_audio.mp3">Audio description of "Mars Landing"</a>

G159: 映像のみの時間依存メディアに対する代替コンテンツを提供する

検証

手順

映像しか含まないコンテンツがあるウェブページに対して:

映像しか含まないコンテンツの直前又は直後に、映像のコンテンツを説明する音声による代替へのリンクがあることを確認する。

期待される結果

1. の結果が真である。

G167: テキストフィールドの目的をラベル付けするために隣接するボタンを用いる

適用 (対象)

フォームをサポートするウェブコンテンツ技術すべて

これは、次の達成基準に関連する達成方法である:

達成基準 3.3.2 (ラベル又は説明)
- クイックリファレンス 3.3.2 (ラベル又は説明)
- 達成基準 3.3.2 (ラベル又は説明)を理解する

解説

テキストフィールド上である機能を実行するボタンがあり、ボタンは明確にラベル付けされていて、テキストフィールドと隣り合って表示される場合、ボタンはテキストフィールドに対するラベルとしての役割も果たす。このラベルは、ページ上に新たな反復的なテキストを追加することなく、利用者がこのテキストフィールドの目的を理解するのを助ける。一つのテキストフィールドをラベル付けするボタンは通常はテキストフィールドの後に置かれる。

注記: このフィールドはまた、達成基準 4.1.2 によって、プログラムによる解釈が可能な名前 (name) を持っていなければならない。

事例

事例 1: 検索機能

あるウェブページには、利用者が検索文字列を入力するためのテキストフィールドと、検索を実行するための「検索」とラベル付けされたボタンがある。ボタンはテキストフィールドの直後に配置されているため、このテキストフィールドが検索のための文字列を入力するためのものであることが利用者にとって明らかである。

画面イメージ: フィールドのラベルを提供するボタンが右側にあるテキストフィールド

事例 2: フォームの選択

あるフォームではアメリカ合衆国の利用者に記入を求めている。州によって法律や要求が異なるので、利用者は自分が居住する州に対応したバージョンのフォームを選択しなければならない。ドロップダウンリストから利用者が州を選択するようになっている。隣接するボタンには「この州のフォームを開く」とラベル付けされている。ボタンを押すと、選択した州のためのフォームを表示するウェブページに移動する。

検証

手順

この達成方法を用いているテキストフィールド及びボタンに対して:

テキストフィールド及びボタンが、プログラムによる解釈がされる読み上げ順序で、互いに隣接していることを確認する。
テキストフィールド及びボタンが互いに視覚的に隣接してレンダリングされていることを確認する。

期待される結果

上記の手順全ての結果が真である。

G168: 選択されたアクションを続行するために確認を求める

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、選択されたアクションが利用者の意図どおりであるかどうか、利用者に対して確認を求めることである。アクションが遂行された後では取消が不可能な場合は、この達成方法を用いる。これによって、利用者が誤ってフォームを送信してしまったり、データを削除してしまったりすることを防ぐことができる。

例えば、利用者が想定していた「送信」ボタンと「キャンセル」ボタンの提示順序が、システムの設定とは逆だった場合、ボタンを早く押し過ぎて予想とは違う順序であることに気付かないことによって、誤操作が起こりうる。利用者に確認の要求を提示することで、間違いに気付き、データの送信を中止する、又は入力したデータが失われないようにすることができる。

確認の要求では、選択されたアクション、及びアクションを継続した場合の結果を利用者に伝えるべきである。

事例

事例 1: 飛行機を利用した旅行

オンラインの旅行サイトで、利用者はいろいろな航空会社の座席の予約をして、旅程表を作成することができる。利用者はその時点での旅程表を確認して、修正したり、キャンセルしたりすることができる。旅行の予定をキャンセルしたいとき、ウェブページ上でその予約を見つけて、旅程表から削除する。このアクションで彼の座席の予約はキャンセルされ、元には戻らなくなる。利用者は選択したアクションによって現在の座席の予約がキャンセルされ、アクションが実行されると同じフライトでの予約が不可能になることを知らされる。利用者は予約を取り消してよいか、又は予約の取消を中止するかの確認を求められる。

事例 2: ウェブメール

ウェブメールのアプリケーションが、インターネットにつながっている場所ならどこからでもアクセスできるように利用者の電子メールをサーバー上に保存している。利用者が電子メールのメッセージを削除する場合、間違って削除してしまっても取り出すことができるゴミ箱フォルダーにメッセージは移動される。ゴミ箱フォルダのメッセージをサーバーから削除するための「ゴミ箱を空にする」コマンドがある。ゴミ箱フォルダーが空にされると、メッセージは 2 度と取り出すことはできなくなる。そのため、ゴミ箱フォルダーを空にする前に、利用者はゴミ箱フォルダの電子メールを削除してよいか、又は削除するのを中止するかの確認を求められる。

事例 3: オンライン上の試験

試験の答案の回収用にフォームが使用されている。「送信」ボタンまたは「リセット」ボタンが選択されると、ウェブページ上で、どちらを選択したかが表示され、続行してよいか確認を求められる。事例 1:「フォームをリセットするを選択しました。入力したデータは全て削除され、回答は送信されません。フォームをリセットしますか？　[はい　ボタン][いいえ　ボタン]」。事例 2:「フォームを送信するを選択しました。入力されたデータはあなたの最終回答として送信され、変更することができなくなります。フォームを送信しますか？[はい　ボタン][いいえ　ボタン]」。

事例 4: 株取引

株取引のサイトで利用者は株や他の証券の売買ができる。取引時間内に利用者が取引を行った場合、取引は即時に処理され、変更不可能であるということがダイログで提示される。ダイアログには、「続ける」ボタンと「中止する」ボタンがある。

検証

手順

元に戻す又は変更が不可能なアクションを始める。
選択したアクションに対して、確認の要求が提示されることを確認する。
アクションを確定することができる、及びアクションを取り消すことができることを確認する。

期待される結果

2.及び 3.の結果が真である。

G169: テキストを左寄せ又は右寄せにする

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.8 (視覚的提示)
- クイックリファレンス 1.4.8 (視覚的提示)
- 達成基準 1.4.8 (視覚的提示)を理解する

解説

認知障害のある利用者の多くは、均等割り付けの (左と右マージンの両方に位置合わせされた) テキストのブロックに大変に苦労する。単語の間の空白は、ページの下のほうへ流れている「リバー (rivers of white)」を作り、一部の人々にとってテキストを読むことが困難になる。この問題を避ける最も良い方法は、テキストを均等割り付けにしないことである。

事例

事例 1

ほとんどのウェブコンテンツ技術において、すべての位置決めの宣言を単純に省く。例えば、以下のテキストは、ページの言語が左から右に流れる HTML において、初期設定として左に揃えられる。

コード例:


<p>
Lorem ipsum dolor sit amet, ...
</p>

事例 2

ウェブページは配置指定が混在した区域を含んでいる。ページの本文の段落は左のマージンに揃えられている。また、テキストには、多くのプルクオートがあり、それらは右のマージンに揃えられている。

訳注: プルクオートとは、大きめの文字で表示された記事からの引用または手を入れた抜粋のことである。英語版 Wikipedia Pull quote も参考にされたい。

検証

手順

一般的なブラウザでページを開く。
コンテンツが均等割り付け (左と右マージンの両方に揃える) になっていないことを確認する。

期待される結果

2.の結果が真である。

G170: 自動的に再生される音声を停止するコントロールを、ウェブページの先頭付近で提供する

適用 (対象)

自動的に再生される音を含むウェブコンテンツ技術全て

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.2 (音声の制御)
- クイックリファレンス 1.4.2 (音声の制御)
- 達成基準 1.4.2 (音声の制御)を理解する

解説

この達成方法の目的は、ページが読みこまれたときに自動的に開始する音声を、利用者が停止できるようにすることである。利用者が容易に素早く見つけることができるように、音声を停止するコントロールはページの先頭付近に配置しなければならない。これは、支援技術 (スクリーンリーダー、画面拡大ツール、入力装置 (スイッチ) など）を利用する人々及びそうでない人々 (認知、学習及び言語障害のある人々) の役に立つ。

この達成方法では、コンテンツ制作者は、自動的に再生されたあらゆる音声を利用者が停止できるコントロールを組み込む。コントロールは、キーボードで操作が可能で、タブと読み込みの順序が早くなるよう配置され、再生されている音声を停止することを示すよう明確にラベルづけされていなければならない。

事例

事例 1

ウェブページは、草刈り機のエンジンを修理する方法を示す動画と音声トラックを含む、時間の経過に伴って変化するメディア提示がある。ページは「一時停止」と「停止」というふたつのボタンを含んでおり、時間の経過に伴って変化するメディアが再生されるとき、これらは利用者にコントロールを提供する。

事例 2

ウェブページには短編映画が埋め込まれている。ページには「映画を一時停止する」というボタンがあり、利用者が映画を一時停止させることができる。

事例 3

ウェブページには動画と音声を含む Flash プレゼンテーションがある。ページには「マルチメディアを停止する」というボタンがあり、再生されているあらゆる動画と音声を利用者が停止できる。

検証

手順

ウェブページをロードする。
自動的に開始する音楽又は音声を確認する。
利用者が音声を停止できるコントロールが、ページの先頭付近で提供されていることを確認する。

期待される結果

3.の結果が真である。

G171: 利用者の要求に応じてのみ、音声を再生する

適用 (対象)

音を再生できるウェブコンテンツ技術すべて

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.2 (音声の制御)
- クイックリファレンス 1.4.2 (音声の制御)
- 達成基準 1.4.2 (音声の制御)を理解する

解説

この達成方法の目的は、ウェブコンテンツにおける音声の使用を利用者が制御できるようにすることである。スクリーンリーダーを使う利用者にとっては、ウェブコンテンツから音声が再生されていると、スクリーンリーダーの音声を聞き取る上で非常に気が散ったり聞き取るのが困難になるかもしれない。利用者の要求によってのみ音声を再生する方法を提供することで、利用者はスクリーンリーダーからの出力と干渉せずに音声を聴くために必要な制御を行えるようになる。

事例

事例 1

あるコククジラ保護団体のウェブページでは、コククジラの鳴き声と水しぶきの音が背景として繰り返し流れるようになっている。その音声は自動的には開始されない。その代わり、ウェブコンテンツには先頭付近に、利用者が手動で再生を開始できるボタンが置かれている。ボタンには「音声を再生」と書かれており、このボタンを押すことで音声が聞こえてくる。再生が始まると利用者には「音声を停止する」という選択肢が提供される。

事例 2

コククジラの音が含まれる音声ファイルへのリンクが提供されている。リンクテキストには「コククジラの鳴き声を聴く (MP3)」と書かれている。

検証

手順

3 秒以上の音声を再生することが既知のウェブページを読み込む。
音声が自動的に再生されないことを確認する。
利用者が手動で音声の再生を開始する方法があることを確認する。

期待される結果

3. の結果が真である。

G172: テキストの両端揃えを解除するためのメカニズムを提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.8 (視覚的提示)
- クイックリファレンス 1.4.8 (視覚的提示)
- 達成基準 1.4.8 (視覚的提示)を理解する

解説

この達成方法の目的は、両端揃えをしていないバージョンのページを提供することである。

コンテンツ制作者は、レイアウトの目的でテキストを両端揃えにしたいと思う場合があるかもしれない。この場合、テキストの両端揃えを解除する機能を提供すればよい。そのためのコントロールは、探し出しやすく、アクセスしやすいように、ページの先頭の近くにおくとよい。

注記: この達成方法は、適合していないコンテンツに対して適合している代替版のページを提示するために、スタイルを切り替える達成方法と組み合わせて用いられる。詳細は、C29: 適合している代替版を提供するために、スタイルスイッチャーを使用する (CSS) 及び適合している代替版を理解するを参照。

事例

事例 1

両端揃えで、元々出版された作業の外観の再現を試みたオンラインの古典小説がサイトにある。「両端揃えを解除する」と書かれたボタンがページの先頭近くにあり、スタイルシートを切り替えるためにスタイルを切り換える達成方法が使用されている。新しいスタイルシートでは、テキストを左揃えで配置する。

C19: CSS でテキストの配置を左寄せ又は右寄せに指定する

検証

手順

両端揃えのページを開く。
両端揃えを解除する機能があることを確認する。
その機能により、両端揃えが解除することを確認する。

期待される結果

2. 及び 3. の結果が真である。

G173: 映像の音声解説付きバージョンを提供する

適用 (対象)

音声及び映像をサポートするあらゆるウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、映像コンテンツに対して音声解説を提供する別のバージョンを用意することによって、目で見ることのできない利用者が視聴覚コンテンツを理解できるようにすることである。

今日のユーザエージェントのほとんどは複数の音声トラックを一つにまとめることができないため、この達成方法では、映像コンテンツのオリジナルの音声トラックと付加的な音声解説を一つの音声トラックにまとめた別のバージョンを提供し、音声による追加の情報を同期したメディアに追加する。この追加された情報は、コンテンツを理解するにあたって重要な行動、登場人物、場面の変化、及びスクリーン上のテキスト (キャプション以外の文字) などに焦点を当てたものである。

ムービーに音声解説を一次的な音声トラックとして含んだ別のバージョンを提供することによって、発話内容を聞くだけでなく登場人物の発話内容からだけでは伝わらない文脈や映像の他の側面も聞く必要がある全盲の利用者にとって、このコンテンツをアクセシブルなものにすることができる。

事例

オペラの映像の二つのバージョンが利用可能である。一つめのバージョンには、音楽だけが含まれている。二つめのバージョンには、舞台上の歌手の行動を説明する音声と音楽の両方が含まれている。
子どもたちの前でパフォーマンスをするジャグラーの映像に、音声解説のあるバージョンが含まれている。音声解説のナレーションでは、ジャグラーが投げ上げている物の数や種類、そのパフォーマンスを見ている子どもたちの反応などが説明されている。

参考リソース

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

検証

手順

音声解説を含むメディアの版を開く。
映像の音声を聞く。
発話の合間が視覚的なコンテンツに関する重要な情報を伝えるために使用されているかどうかを確認する。
代替版が別のページにある場合、利用者が他の版にアクセスできるリンクが利用可能できることを確認する。

期待される結果

3. 及び 4. の結果が真である。

G174: 利用者が十分なコントラストのある提示に切り替えられるように、十分なコントラスト比のあるコントロールを提供する

適用 (対象)

あらゆるウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

解説

テキストとそのページの一部の背景の間のコントラストが達成基準 1.4.3 または 1.4.6 のコントラストレベルを満たすように作られていない場合、適合要件 1 における「代替版」を用いることでこれらのガイドラインを満たすことが可能である。ページのリンク又はコントロールは、ページを変更することによって全ての側面を適合させたり、閲覧者を求められるレベルに適合した新しいバージョンのページに導いたりすることができる。また、そのリンクまたはコントロールをウェブページ上の目立つところに置くことによって、利用者が適合しているコンテンツにアクセスしやすくなる。

この達成方法を正しく用いるためには、次の三つを満たさなければならない。

オリジナルページにあるリンクやコントロール自身は、求められる達成基準のコントラスト要求を満たさなければならない (もし利用者がコントロールを見ることができない場合、新しいページに行くためにそれを使用することができないかもしれない)。
新しいページはオリジナルページと同様に全ての情報と機能性を含んでいなければならない。
新しいページは求められる適合レベルのための全ての達成基準に適合すべきである (つまり、新しいページは求められたコントラストレベルは確保しているが他は適合していないということであってはならない)。

この達成方法は、ページの代替版のテキスト (又はテキストの画像) に背景と 4.5:1 のコントラストがある、及び大きいサイズのテキスト (又は大きなテキストの画像) に背景と 3:1 のコントラストがあることによって達成基準 1.4.3 を満たすために用いることができる。もしページの代替版に 7:1 のコントラストのあるテキスト (テキストの画像) と 4.5:1 のコントラストのある大きいサイズのテキスト (又は大きなテキストの画像) があるならば、それは達成基準 1.4.3 と 1.4.6 の両方を満たしている。

注記: この達成方法は、不適合コンテンツのための適合している代替版である現在のページにスタイルを切り替える達成方法と組み合わせることで用いることができる。詳しくは、 C29: 適合している代替版を提供するために、スタイルスイッチャーを使用する (CSS) と適合している代替版を理解するを参照。

事例

3:1 のコントラスト要件を満たしていない見出しがあるページでは、すべてのテキスト及び文字画像で最低限 4.5:1 のコントラストを持つ新しいバージョンのページに移動させるハイコントラスト (5:1) のリンクがページの上部にある。
ページが効果のため陰影のある背景を使っていて、結果として背景とテキストのコントラストは 4:1 しかない。ページのトップにあるコントロールは「ハイコントラスト」となっていて、それをクリックすると異なるスタイルとなり、7:1 のコントラストを達成するように背景色が変わる。

検証

手順

オリジナルページ上に代替版へのアクセスを提供するリンク又はコントロールがあることを確認する。
オリジナルページのリンク又はコントロールが、テストされている適合レベルの全ての達成基準に適合していることを確認する。
代替版が、テストされている適合レベルのコントラスト及び他の全ての達成基準を満たしていることを確認する。

期待される結果

上記の全ての結果が真である。

G175: 背景色及び前景色のための複数色選択ツールをページ上で提供する

適用 (対象)

利用者が他のページで再利用するために設定を保持できる全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.8 (視覚的提示)
- クイックリファレンス 1.4.8 (視覚的提示)
- 達成基準 1.4.8 (視覚的提示)を理解する

解説

この達成方法の目的は、ウェブページ又はウェブページ一式にコントロールを組み込み、利用者がコンテンツに対して好みの前景色及び背景色を指定できるようにすることである。この達成方法は、利用者が複数のページにわたって利用可能な設定を保持可能なウェブコンテンツ技術であればどれを用いても実装することができる。コンテンツ制作者はこの達成方法を使用して、利用者がサイト内の他のページでも使用可能な好みの前景色及び背景色を選択し、保存できるカラーピッカーコントロールを組み込む。ページは、この設定を検索し、保存された設定が見つかる場合にそれに従って適応するように設計されている。

認知障害のある利用者の多くは、標準的な白い背景に黒いテキストがあるページを読むのに苦労している。テキストと背景に別の色を用いるとテキストが格段に読みやすくなる場合があるが、これらの色の組み合わせは個別性が高く、他人には想定しにくい (例えば青の背景色に茶色のテキスト)。

このような利用者は、ブラウザの色の設定機能、又は OS の色の設定機能を使って色を設定することが困難なことがある。ウェブページ上に前景及び背景の広範な色の指定ができるツールを提供して、ブラウザの設定の中まで進まなくても簡単に色を変更することができるようにする。

事例

事例 1

利用者がテキストフィールドに 16 進数の値を入力できる。又は、"Pick" (選択) のリンクで隣接したフィールドに対する色選択ツールを開く。

スクリーンショット: 16 進数の値が入力された複数のテキストフィールドで前景色と背景色を設定するカラーコントロールを表示している。それぞれのフィールドにはラベルとテキストフィールドの中間に配置されたカラーピッカーを開くリンクがある。

色を選択するために色選択ツールを開く。

スクリーンショット: カラーピッカーのある色選択ツールが前景色を選択するために開いており、利用者は 216 色の中から選べるようになっている。

PHP、Javascript、CSS 及び XHTML を使って実装した、この達成方法の実装例がある: カラーピッカーの例

参考リソース

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

検証

手順

ページ上に色選択ツールとして特定されるコントロールがあることを確認する。
色選択ツールでテキスト及び背景色のために様々な色の選択ができることを確認する。
そのツールを使ってテキスト及び背景に新しい色を選択する。
コンテンツが選択した色の組み合わせに更新されることを確認する。

期待される結果

1. 及び 4. の結果が真である。

G176: 閃光を放つ領域を十分に小さくする

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 2.3.1 (3 回の閃光、又は閾値以下)
- クイックリファレンス 2.3.1 (3 回の閃光、又は閾値以下)
- 達成基準 2.3.1 (3 回の閃光、又は閾値以下)を理解する

解説

この達成方法の目的は、閃光を放つが小さいものに関して、達成基準を満たす容易な方法を提供することである。

ある 1 秒間において 3 回以上の閃光を放つものがある (つまり、G19 の達成方法を用いることができない) が、閃光を放つ領域が視野 10 度 (これは視界における中心視野に相当する) の 25％未満である場合、自動的に達成基準を満たすことになる。

視野 10 度は、視界における中心視野にあたる。この視野には、視覚センサーがたくさんある。この視野における閃光は、視覚野に送られる。光過敏性発作のある利用者は、視覚野上において閃光を受け取ることで発作を引き起こす恐れがある。その他の視野 (視覚センサーがずっと少ない部分) での閃光は、視覚野に与える影響がずっと少ない。そのため、中心視野の 10 度だけを対象とする。

コンテンツを一般的なウェブで使用する場合には、公式 1: ウェブコンテンツにおける小さくて安全な領域を用いることができる。
コンテンツを既知のディスプレイ (例: 会社のロビーにあるディスプレイ) で使用する場合には、公式 2: 既知のディスプレイにおける小さくて安全な領域を用いるべきである。

公式 1: ウェブコンテンツにおける小さくて安全な領域

ほとんどのウェブコンテンツ制作者は、視野をピクセルに変換する方法を知らない。が、それは一般に対処可能なものである。この達成方法では、その変換方法を提供する。

この文書を執筆している時点では、最も一般的なディスプレイの解像度は 1024 x 768 ピクセルで、画面は約 15～17 型である。一般的な画面との距離 (56～66 センチメートル) で閲覧している際、視野 10 度はおおよそ 341 x 256 ピクセルの領域を占めることになる。これは円形ではないが、ほとんどの利用者の中心視野も円形ではない。その差異はとても小さいので (そして、中心視野でも視覚センサーの少ない端のことなので)、重要なことではない。

基準は視野 10 度の 25% なので、(画面上に他に閃光を放つものがなければ) 画面上で (どんな形であれ) 21,824 平方ピクセルの隣接した領域よりも小さい単一の閃光を放つものは、一般閃光)及び赤色閃光の閾値を下回っていることになる。

1024 x 768 ピクセルの画面解像度は、それが最も一般的であるという理由で選ばれている。よりぎっしり詰まったピクセル密度ではより小さくより安全な画像サイズになるので、高解像度のディスプレイでも前述の内容は通用する。

低解像度のディスプレイ、拡大した画面、又はより近い画面との距離で閲覧している利用者は、その画面との距離によっては危険が高まることになる。そのような利用者のニーズに対処するためには、画面解像度又は画面との距離に依存しない達成方法であるということで G19: どの 1 秒間においても、コンテンツに 3 回よりも多く閃光を放つコンポーネントがないことを確認するを用いるべきである。

公式 2: 既知のディスプレイにおける小さくて安全な領域

画面サイズ、解像度、及び画面からの距離が明らかな際に画面上の小さくて安全な領域を (ピクセルで) 計算するには、次の手順を用いる。

注記: (中心視野のセンサーの分布は円形ではない、簡易さ、計算上の便宜、歴史的) など幾つもの理由から、中心の視野 10 度に相当する 4:3 の矩形の近似値が用いられる。それは 10 度の幅と 7.5 度の高さに相当する。これは、75 平方度の領域を持ち、10 度の真円の 78.5 平方度に相当する領域である。

画面との距離を矩形サイズに変換するには、その画面との距離に 0.1745 (10 * Pi / 180) を掛けて矩形の幅を算出し、画面との距離に 0.1309 (7.5 * Pi / 180) を掛けて矩形の高さを算出する (この計算は、インチ、ミリメートル、又はその他のあらゆる長さの単位で用いることが可能)。
視野角 10 度のサイズをピクセルで定める。
それには、単位長さあたりピクセルで、手順 1 で算出した矩形の幅及び高さに画面解像度を掛けて、矩形の水平方向及び垂直方向のサイズをピクセルで算出する。
- 1080p (1920 x 1080 ピクセル) のワイドスクリーンのディスプレイの場合、ピクセルパーインチでの画面の解像度は、2203 を対角線の画面サイズ (インチ) で割った数になる。
- 720p (通常は、1365 x 768 ピクセル) のワイドスクリーンのディスプレイの場合、ピクセルパーインチでの画面の解像度は、1566 を対角線の画面サイズ (インチ) で割った数になる。
- ピクセルピッチをミリメートル又はピクセルで指定した LCD のコンピュータのモニタの場合、ピクセルパーインチでの画面の解像度は、25.4 をピクセルピッチ (ミリメートル) で割った数になる。
どんなディスプレイでも、実際の対角線の画面サイズがインチでわかっていて、ディスプレイの水平方向と垂直方向の解像度がピクセルでわかっている場合、ピクセルパーインチでの画面解像度は、((水平方向の解像度:ピクセル) x (水平方向の解像度:ピクセル) + (垂直方向の解像度:ピクセル) x (垂直方向の解像度:ピクセル)) の平方根である。
矩形の幅に高さを掛けて、4 で割る。

事例

コンテンツ制作者が、会社の入口ラウンジにあるスクリーンで流れるアニメーションを制作する。ディスプレイのサイズ及び画面解像度とディスプレイを見る際の最も近い画面との距離から、中央視野 10 度の 25 ％をピクセルで計算している (前述の公式を使用)。これは小さくて安全な領域といえる。コンテンツ制作者は、その小さくて安全な領域よりも大きい領域で閃光を放つことがないように留意している。

参考リソース

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

検証

手順

小さくて安全な領域を計算する。
どのタイミングにおいても画面の一つの領域だけが閃光を放っていることを確認する。
閃光を放つコンテンツは、小さくて安全な領域よりも小さい連続したコンテナ内に収まっていることを確認する。

期待される結果

2. 及び 3. の結果が真である。

G177: テキストの修正候補を提示する

適用 (対象)

フォーマット、値及び又は入力のタイプに制限があり、利用者のデータ入力を受け付けるコンテンツ

これは、次の達成基準に関連する達成方法である:

達成基準 3.3.3 (エラー修正の提案)
- クイックリファレンス 3.3.3 (エラー修正の提案)
- 達成基準 3.3.3 (エラー修正の提案)を理解する

解説

この達成方法の目的は、利用者が入力した情報が受け付けられないとき、正しいと思われるテキストを推測できる場合には、そのテキストを提示することである。修正候補としては、正しい綴りのテキストや、あらかじめ蓄積されているテキスト群にある類似したテキストなどが含まれる。

フォームによって修正候補の提示方法は異なるが、エラーが発生した入力欄の横、ページの他の部分に表示することもできるし、検索機能やリンクを用いて修正候補の一覧が掲載されている他の URI に誘導することもできる。可能であれば、修正候補は利用者にとって利用しやすい方法で提示すべきである。たとえば、誤った情報が送信されたとき、利用者が意図した内容をチェックボックスやラジオボタンを用いて選択できるような形式で修正候補の一覧を提示するような方法が考えられる。修正候補や修正候補へのリンクは、たとえば、フォームの先頭、エラーがあるフィールドの直前または直後など、エラーを含むしたフォームフィールドの近くに配置しなければならない。

事例

あるフォームフィールドでは、日単位から年単位で時間の長さを入力することが求められている。利用者が "6" と入力してフォームを送信すると、サーバーは利用者が入力した内容をそのまま残した上で、入力フィールドの横に「エラー: 6 日、6 週間、6 ヶ月、6 年のいずれかを入力してください」というテキストも返す。
利用者が、間違った都市名を入力したとする。サーバーは、利用者がフォームを送信したときにフォームを返す。また、フォームの最上部に、都市名のデータベースと元の入力を比較することで判定される、エラーを通知するメッセージと、利用者が意図した都市名のリストへのリンクが含まれている。
あるバスの経路検索のシステムでは、利用者が住所、交差点の名前、目印となる建物などを入力して出発地と目的地を指定できる。利用者が "Kohl" と入力すると、「"Kohl" の検索結果は以下の通りです」という類似の検索結果のリストが表示される。利用者が選択できるオプションとして、続くセレクトボックスに "Kohl Center"、"Kohl's Dept. Store-East" 及び "Kohl's Dept. Store-West" が列挙されている。
検索を実行すると、入力されたテキストに対するスペルチェックが実行される。エラーが発見された場合には、修正候補へのリンクを表示する。利用者が修正候補から正しい綴りのテキストを選択してそのリンクをクリックすると、その単語が入力されたものとして検索フォームの内容が再送信される。

検証

手順

誤ったテキストから正しいテキストを推測可能なフォームフィールドを特定する。
フォームに入力し、特定したフィールドに意図的に誤ったテキストを入力する。
利用者に対して正しいテキストの修正候補が提示されることを確認する。
フォームフィールドの横に修正候補が表示される、又は修正候補へのリンクがフォームフィールドの近くに配置されていることを確認する。

期待される結果

3. 及び 4.の結果が真である。

G178: 利用者がウェブページ上のすべてのテキストを 200％まで徐々に変更できるコントロールをウェブページ上で提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.4 (テキストのサイズ変更)
- クイックリファレンス 1.4.4 (テキストのサイズ変更)
- 達成基準 1.4.4 (テキストのサイズ変更)を理解する

解説

この達成方法の目的は、文字のサイズを徐々に大きくするメカニズムをウェブサイト上で提供することである。多くのロービジョンの人々は拡大鏡ソフトウェアを使っておらず、そしてブラウザの文字サイズの調整について精通していない。このことは、あとからコンピューターを学んだり、また失明に近い症状の高齢者にも特に当てはまる。これはフォントサイズを大きくしたいと思っている認知障害者もまた同様である。

この達成方法は、利用者がより簡単に使うことのできるメカニズムを提供する。このメカニズムは視覚的提示を異なるスタイルシートに切り替えたり、文字サイズをダイナミックに変化するためのスクリプトを使用したりするリンクやボタンを含んでいる。

この達成方法を実装するために、コンテンツ制作者は利用者がページ上のすべてのテキストの文字サイズをデフォルト文字サイズの少なくとも 200％の大きさに徐々に増加又は減少させるコントロールを提供する。

これはリンクやボタンまたはリンク画像によって達成可能であり、そしてそれらコントロールは可能な限り簡単に見つけられるべきである。(ページ内で目立つ場所にある、大きなテキスト、ハイコントラストで表現されているなど。)

この達成方法は、レガシーコードの場合のように、拡大縮小可能なフォントを用いることができない状況でも同様に用いることができる。

注記: この達成方法は、不適合コンテンツのための適合している代替版のページを表示させるためのスタイル切り替えの達成方法との組み合わせで用いることができる。更なる情報は C29: 適合している代替版を提供するために、スタイルスイッチャーを使用する (CSS) と適合している代替版を理解するを参照。

事例

新聞記事のページ上部に二つのボタンがある。「文字サイズを大きくする」ボタンは上矢印と大文字「T」、「文字サイズを小さくする」ボタンは下矢印と小文字「T」がある。それぞれのボタンには alt テキストがある。
サイトは、異なる文字サイズの複数のスタイルシートを持つ。ブラウザがこの機能を提供する場合、利用者はスタイルシートのいずれかを選択できる。各ページには、各ページには現在適用されているスタイルシートを適切な代替スタイルシートに変更するリンク「文字サイズを大きくする」と「文字サイズを小さくする」も含まれている。
サイトは、すべてのウェブページで「文字サイズを変更」というテキストの後に「上へ」および「下へ」のテキストリンクを含んでいる。リンクは、それに応じて text-size プロパティの値を変更する Javascript をトリガーする。
サイトは、「文字サイズを変更する」と表示されているすべてのページにリンクが含まれている。結果のページには、利用可能なサイズを表すオプションを含む一連のリンクが含まれている。リンクは、「最小フォントサイズ」、「小さいフォントサイズ」、「デフォルトフォントサイズ」、「大きいフォントサイズ」などが表示されている。

検証

手順

ビューポートのサイズを 1024px × 768px 以上に設定する。
テキストサイズを大きくして、テキストサイズが大きくなるかどうかを確認する。
テキストサイズが元のサイズから 200％に大きくすることができることを確認する。
テキストサイズが元のサイズから 200％に大きくした後、コンテンツ又は機能が損なわれていないことを確認する (例えば、テキストの一部が表示されなくなる、ボックスが重なり合う、コントロールが隠れてしまったりラベルから離れてしまったりする、というような状態にならない)。
テキストサイズを初期値まで小さくし、実際に初期値に戻っていることを確認する。

期待される結果

2. ～ 5. の結果が真である。

G179: 文字サイズを変更し、かつテキストコンテナの幅を変更しないときに、コンテンツ又は機能が損なわれないようにする

適用 (対象)

ウィンドウのサイズを変更するとテキストを折り返す、全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.4 (テキストのサイズ変更)
- クイックリファレンス 1.4.4 (テキストのサイズ変更)
- 達成基準 1.4.4 (テキストのサイズ変更)を理解する

解説

ユーザエージェントの中には、テキストコンテナの幅又は高さを変えることなく、文字サイズの変更をサポートしているものがある。コンテンツ又は機能の損失は、テキストがその割り当てられたスペースからあふれてしまう時に起こりうる。しかし、レイアウトのプロパティは、コンテンツの表示を効果的に継続する方法を提供することができる。ブロックのサイズは、200% まで変更した時に文字があふれないほどの十分な幅を定義している。文字はブロック内に入りきらない時包まり、そしてブロックは、ブロック内にすべての文字が入り続けるために十分な高さとなる。ブロックは変更された文字が入りきらない時、スクロールバーを提供する。

事例

事例 1: マルチカラムページレイアウト

HTML と CSS はテキストのページのために２つのカラムのレイアウトを作るために使われている。white-space 特性と normal のデフォルト値を使うことで文字を包み込んでいる。文字のサイズが 200 ％になると、文字は再びあふれ、テキストのカラムは長くなる。もしカラムが表示域に対して長すぎると、コンテンツ制作者が overflow:scroll 又は overflow:auto の CSS ルールを指定しているため、ユーザエージェントはスクロールバーを提供し、利用者がビューの中にテキストをスクロールすることができるようにする。

事例 2

カラムの中でテキストブロックでレイアウトしている新聞がある。そのブロックは横幅は固定されているが、高さは指定していない。ブラウザでテキストが変更された時、文字は包まれ、ブロックは高さが高くなる。

検証

手順

テキストサイズを 200％に拡大する。
全てのコンテンツ及び機能が利用可能であるかどうかを確認する。

期待される結果

2. の結果が真である。

G180: 利用者がデフォルトの制限時間を 10 倍に設定できる手段を提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.1 (タイミング調整可能)
- クイックリファレンス 2.2.1 (タイミング調整可能)
- 達成基準 2.2.1 (タイミング調整可能)を理解する

解説

この達成方法の目的は、障害のない利用者に比べて障害のある利用者が長時間必要とするかもしれないタスクにおいて、障害のある利用者に完了するための十分な時間を提供することである。環境設定又はページ上のコントロールのようなメカニズムによって、利用者がデフォルトの制限時間の少なくとも 10 倍まで制限時間を延長できるようにする。可能であれば、このメカニズムはさまざまな調整機能を備え、利用者が制限時間を範囲内の任意の値に変えられるだけでなく、任意の増減幅で変えられる方法も提供するとよい。これにより、利用者は、制限時間のあるセッションを始める前に、制限時間を変更できるようになる。

事例

航空会社が、オンラインで航空券を購入するためのアプリケーションを提供している。このアプリケーションは、購入プロセスの各ステップに対して 1 分間の制限時間をデフォルトで設定している。セッションの開始時に、「購入プロセスの各ステップには制限時間があり、1分以内に完了させる必要があります。この制限時間を調整しますか？」とウェブページに表示され、続いて「1 分」「2 分」「5 分」「10 分」などのラジオボタンがいくつか表示されている。
ウェブベースの E メールアプリケーションで、30 分間利用者の操作がないと、自動的にログアウトするようになっている。このアプリケーションには、利用者がタイムアウト時間を任意の値に調整できる環境設定が含まれている。

検証

手順

制限時間をデフォルトの 10 倍に設定するメカニズムがあるかどうかを確認する。
制限時間をデフォルトの 10 倍にあたる新しい値に変更する。
制限時間のあるタスクを遂行する。
デフォルトの制限時間が経過するのを待つ。
上記 2. で設定した制限時間になるまで時間切れにならない。

期待される結果

1. 及び 5. の結果が真である。

G181: 利用者のデータを、再認証したページで非表示データ又は暗号化されたデータとしてエンコーディングする

適用 (対象)

データを送信するのに、利用者認証を求め制限時間のあるウェブページ

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.5 (再認証)
- クイックリファレンス 2.2.5 (再認証)
- 達成基準 2.2.5 (再認証)を理解する

解説

利用者に認証を求めるウェブサーバーは、一定時間、利用者の操作がない場合、セッションを終了することがよくある。利用者が素早くデータを入力できず、送信前にセッションが時間切れになってしまった場合、プロセスの続行前にサーバーから再認証が求められるだろう。この場合、サーバーはフォームからの情報 (隠しデータ) を再認証ページに受け渡す。その後、利用者が再認証したら、フォームデータを直接送信するか、確認データを含んだページを表示するために、サーバーは再認証ページから受け渡された情報を利用する。この達成方法では、サーバーは利用者が送信したデータを保存しておかなくてもよい。この達成方法が重要なのは、サーバーに一時的に情報を保存することが、違法性やセキュリティリスクに関わるケースである。また、サーバーが記録した情報を保持しつづけたり、新しく認証したセッションでその情報に再接続する必要性から解放する点でも有用である。

注記: 利用者から送信されたデータが機密情報であったり、セキュリティリスクの疑いがある場合、データを再認証ページに受け渡したり、再認証後、データ保護を保証するために元のデータを処理してページに受け渡すプロセスを、コンテンツ制作者は見直すべきである。

事例

ある Wiki に利用者がログインし、ページの編集を始めた。編集の完了にかかる時間は、サーバーから許可されている不操作セッション時間よりも長いとする。利用者が編集データを送信したが、セッションの時間切れが通知され、ログインページにリダイレクトされた。フォーム送信を処理するスクリプトは、ログインページに元の編集データを変数として受け渡す。利用者のログインが成功すれば、編集画面に戻ることができ、まるでセッションの時間切れがなかったかのようにスクリプトが編集データを処理する。
セキュリティが保護されたショッピングサイトに利用者がログインし、注文フォームに情報を入力している。セキュリティ上の理由から、セッションは 30 分後に時間切れとなるが、その利用者はページを読み込んでから 45 分経ってもまだフォームデータを送信していない。利用者には時間切れが通知され、再ログインが促された。利用者が正しくログインできれば、以前に入力したデータが全て残った注文フォームが表示され、内容を確認し、送信できる。ログインが成功しなければ、サーバーによってフォームデータが破棄される。

G105: 利用者が再認証した後に利用できるようにデータを保存する

検証

手順

データの送信にあたって利用者にログインを求めるサイトについて:

ログインし、時間制限のある操作を始める。
セッションを時間切れにさせる。
データを送信する。
再認証する。
再認証後に元のデータ及び変更内容が保持された状態で、その後のプロセスが継続可能で、データの欠落なく完了できることを確認する。
手順 3.で送信した情報を保存するために用いた途中経過のデータが、サーバーに残っていないことを確認する (注記: この手法を実行するための技術及び機能の知識が必要である)。

期待される結果

5. 及び 6. の結果が真である。

G182: 文字色の違いが情報を伝えるために使用される場合に、利用可能な追加の視覚的な手がかりを確保する

適用 (対象)

次のように、色を用いて情報を伝えている際の色つきのテキスト:

パラグラフ内でリンクになっている語句
リスト内で、他のリスト項目とは異なり、色つきのテキストで提示されているリスト項目

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.1 (色の使用)
- クイックリファレンス 1.4.1 (色の使用)
- 達成基準 1.4.1 (色の使用)を理解する

解説

この達成方法の目的は、テキストの色の違いを識別することができない利用者に対して、同じ情報を示す豊富な視覚的な手がかりを提供することである。パラグラフの一部である語句又はテキストの他のブロックの一部である語句とは異なるステータスを示すために、又は特殊な文字あるいはグラフィックを用いて特別なステータスを有する語句を示すことができない場合に、色をよく用いる。例えば、テキスト内に散在している語句は、異なる色で表示されていれば、それがハイパテキストのリンクであることを示している可能性がある。この達成方法は、色の違いを知覚するのが困難な利用者又はロービジョンの利用者にその違いが分かるように、色に加えて手がかりを提供する方法に関するものである。

この達成方法を用いるにあたり、色だけを用いて情報を伝えている全ての箇所に対して、コンテンツ制作者は色に加えて視覚的な手がかりを提供する。視覚的な手がかりには、フォントのスタイル、下線の付加、太字、イタリックへの変化、又は文字サイズの変化などをはじめ、様々な形態が考えられる。

注記: この達成方法が達成基準 1.4.1 の視覚的な必須要件を満たしている時、色によって伝えられる情報は、達成基準 1.3.1 も満たすようプログラムで利用可能でなければならない。How to Meet 1.3.1 を参照のこと。

事例

同じページ上の他のテキストと異なる色で表示し、また色が識別できなくともリンクを識別できるよう下線とともに表示するのが、リンクの標準的なフォーマットである。
様々なマークアップ言語における似た要素の使用法を比較した記事で、色つきのテキストを用いて各言語の要素を示している。一つめのマークアップ言語の要素には青色の太字のテキストを用い、二つめのマークアップ言語の要素には、赤色のイタリックのテキストを用いている。
あるニュースサイトでは、そのサイトに掲載されている記事の見出しを一覧にしている。例えば、その記事が掲載されているセクション、その記事が掲載された時刻、関連する場所、又はライブの映像があることを示す表示などの補足的な情報がある場合もある。そのような補足的な情報は、その記事へのリンクとは異なる色で提示されているが、利用者がリンクをより容易に見つけられるように、各リンクはその他のテキストよりも大きなフォントで提示されている。
短めのニュース項目には、より詳細な情報へのリンクでもある文を含んでいることがある。パラグラフの残り部分では黒色の Times-Roman という書体を用いているが、それらの文には色がついていて、サンセリフの書体を用いている。

検証

手順

テキストの色を用いて情報を伝えている全ての箇所を探す。
色を用いて情報を伝えているテキストは、スタイルも変えているか、又はその周囲にあるその他のテキストと視覚的に区別がつくフォントを用いていることを確認する。

期待される結果

2.の結果が真である。

G183: 色が単独でリンク又はコントロールを特定する場所で、周囲のテキストと一緒に 3:1 のコントラスト比を使用し、そのリンク又はコントロールのフォーカスに追加の視覚的な手がかりを提供する

適用 (対象)

段落中にあるリンクの文字列のように、情報を伝達するために色だけが使われているテキスト

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.1 (色の使用)
- クイックリファレンス 1.4.1 (色の使用)
- 達成基準 1.4.1 (色の使用)を理解する

解説

この達成方法の目的は、テキストの色の違いを識別することができない利用者に対して、同じ情報を示す豊富な視覚的な手がかりを提供することである。色は、段落や他のテキストのブロックの中にある文字列がリンクであることを示すために、一般的に使用されている。例えば、テキスト中に散らばる文字列が、周囲のテキストとの色の違いだけでハイパーテキストのリンクであると認識される。この達成方法は、色の違いを知覚することが困難である、又はロービジョンである利用者がそれらを見分けることができるよう、カーソルを重ねたりフォーカスが当たったときに、手がかりを補足する方法を説明している。

利用者がカーソルを合わせるか Tab キーでリンクに移動するとき、この達成方法とともに視覚的な補足の確認手段があれば、テキストとその周りの相対輝度 (明るさ) の差を 3:1 かそれ以上にしてもよい。視覚的なハイライトとは、例えば、アンダーライン、太字又は斜体といったフォントスタイルの変化、又はフォントサイズが大きくなるといった形になる。

この達成方法を使うことは、この達成基準を満たすために十分であるが、リンクテキストを区別するには、好ましい達成方法ではない。これは、色の相対輝度だけを使用するリンクは、全色盲の人々には分からないかもしれないからである。もしテキストのブロックに大量のリンクがないならば、リンクにはアンダーラインが推薦される。

注記 1: この達成方法は輝度に加えて色の使用に関するものである。この達成方法では、コントラスト比はリンクとその周囲の語句とのコントラストについて言及している。達成基準 1.4.3 と 1.4.6 では、コントラスト比は単語とその背景とのコントラストについて言及している。この違いは、達成基準 1.4.3 と 1.4.6 に使用されるコントラスト比は、異なる色覚及び視覚障害のための、テキストとその背景の可読性に関するものであるが、この達成方法は利用者がテキストの異なる部分の違い (明らかな違い) を識別する能力に関するものだからである。

注記 2: コンテンツ制作者がこの達成方法の色の部分を使用したい (すなわち、互いに十分なコントラストが確保されている異なる色を語句に使用する) と望んでいて、かつ、コンテンツ制作者が達成基準 1.4.3 にも適合したい (それぞれの語句と背景とのコントラストを確保する) 場合、以下で挙げる色を用いることができる。(例えば、白い背景の段落内で黒いテキストを使い、リンクは以下の事例 1 にある色のいずれかで表現する)。

注記 3: もしある時点でのすべての支援技術又はウェブブラウザが、利用者のためにウェブページのすべてのリンクにアンダーラインを引く選択肢を提供するなら、これは、コンテンツ制作者によって提供されたリンクをハイライトするメカニズムの代わりに使用することができる。

事例

事例 1: 黒い文字列に 3:1 のコントラスト、及び白地に 4.5:1 のコントラストを提供する色

この事例のサンプル: 周囲のテキストと 3:1 のコントラスト比を持つリンク

事例 2

ドキュメントのハイパーテキストのリンクは中位の明るい青 (#3366CC) で、通常のテキストは黒 (#000000) である。なぜなら青のテキストは十分に明るく、周囲のテキストと 3.9:1 のコントラストを持ち、まったく色を見ることができない人も含め、すべての種類の色覚障害を持つ人々が周囲のテキストと違うことを識別することができるからである。

参考リソース

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

訳注: 「Colour Contrast Analyser」は 2018 年現在、Firefox Add-ons から入手できない状態にある。

検証

手順

テキストにおいて、情報を伝えるために色だけが使われているすべての箇所を見つける。
テキストの色の相対輝度が、周囲のテキストの相対輝度と少なくとも 3:1 のコントラスト比の違いがあることを確認する。
リンクへのポインティング (マウスオーバー) が、視覚的に強調 (アンダーラインやフォントの変更など) を引き起こすことを確認する。
キーボードフォーカスをリンクに移動すると、視覚的に強調 (アンダーラインやフォントの変更など) を引き起こすことを確認する。

期待される結果

2.、3.、及び 4. の結果が真である。

G184: フォーム又はテキストフィールド一式の先頭に、必須の入力を記述するテキストの説明を提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 3.3.2 (ラベル又は説明)
- クイックリファレンス 3.3.2 (ラベル又は説明)
- 達成基準 3.3.2 (ラベル又は説明)を理解する
注記: この達成方法は、達成基準 3.3.2 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 3.3.2 を理解するを参照すること。
達成基準 3.3.5 (ヘルプ)
- クイックリファレンス 3.3.5 (ヘルプ)
- 達成基準 3.3.5 (ヘルプ)を理解する

解説

この達成方法の目的は、利用者が入力しなければならないデータのフォーマットに関する制限を事前に知らせることによって、利用者が入力エラーを回避するのを助けることである。そのような制限に関する情報を一連のフォームの先頭で提示する。この方法は、少数のフィールドからなるフォーム、又は複数のフィールドが同じフォーマットのデータを要求するようなフォームにおいて最も有効である。このようなケースでは、フォーマットの説明をフォームの先頭に置く説明文で一度だけ提示するほうが、同じ説明を同一のフォーマット制限が要求されるフィールドすべてについて繰り返すよりも効果的である。

事例

事例 1

あるビジネスネットワーキングのサイトでは、利用者が自分の職歴に関する説明を投稿することができる。情報を入力するフォームには、企業名、役職、業務開始及び終了年月日、そして業務の説明などのフィールドがある。フォームの先頭には以下のような指示がある:

「あなたのプロフィールに追加したい職歴について、必要事項を入力してください。日付は yyyy/mm/dd の形式 (例: 2009/01/01) で入力してください。」

事例 2

ある企業内アドレス帳では、利用者が自分のプロフィールを編集して、電話番号や職務内容をカスタマイズできるようになっている。フォームの先頭には以下のような指示がある:

入力欄に表示された任意の情報を変更することができます。「終了」を選択すると情報が記録され、プロフィールを公開することができます。変更を破棄したい場合は「中断」を選択してください。
プロフィール中で、入力欄外にシステムのテキストとして表示された情報は変更できません。これらの情報は企業内人事情報から取得しています。編集できない部分に誤りや更新すべき情報がある場合は、表示情報の隣にあるヘルプアイコンを選択すると修正方法を確認できます。
電話番号は半角の数字とハイフン (-) のみ入力できます。
必須の入力欄はアスタリスク (*) で示されており、入力しなければフォームを完了できません。

G89: 期待されるデータ書式及び入力例を提供する

検証

手順

利用者の入力データを所定のフォーマットでのみ受け付けるフォームコントロールを特定する。
フォームの先頭に、1.で特定したそれぞれのフォームコントロールの所定のフォーマットに関する指示があるかどうかを判断する。

期待される結果

2.の結果が真である。

G185: ホームページからサイト上の全てのウェブページにリンクする

適用 (対象)

リンク機能を提供する全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.5 (複数の手段)
- クイックリファレンス 2.4.5 (複数の手段)
- 達成基準 2.4.5 (複数の手段)を理解する

解説

この達成方法の目的は、利用者が小規模なウェブサイト内の全ての情報を探し出すことが可能となるように、ホームページから全てのウェブページへのリンクを提供することである。サイトのページ数が十分に少ない時、ホームページにおいて直接サイトマップの情報を提供することができる。ウェブサイト内のホームページ以外のページは、ホームページへのリンクを提供する。

このように、ホームページに一つで二つのメカニズムを持たせることができる。一つは各ページへの通常のナビゲーションを提供することであり、もう一つはサイトの事実上のサイトマップにもなることである。

サイト内の全てのウェブページは、全ての他のページへのリンクを提供し、一連のそれらのリンクは達成基準 3.2.3 (一貫したナビゲーション)を満たしている。

事例

コンサルタントのための小規模な商用ウェブサイトは、ホームページ、コンサルタントにコンタクトを取るための問い合わせページ、コンサルタントの経歴を説明しているページ及びコンサルタントの仕事の事例があるページを提供している。個々のページは、サイト内の全ての他のページにリンクするナビゲーションバーを提供している。

検証

手順

ホームページは、ウェブサイト内の全ての他のページへのリンクを提供している。
ウェブサイト内の他のページは、ホームページへのリンクを提供している。

期待される結果

上記全ての結果が真である。

G186: 動きのあるコンテンツ、点滅するコンテンツ、又は自動更新するコンテンツを停止させるコントロールを使用する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.2 (一時停止、停止、非表示)
- クイックリファレンス 2.2.2 (一時停止、停止、非表示)
- 達成基準 2.2.2 (一時停止、停止、非表示)を理解する

解説

この達成方法の目的は、動きのあるコンテンツや点滅するコンテンツを、利用者が停止できるコントロールを提供することである。このようなコントロールがウェブページ上にあれば、そのコントロール自体は適切なレベルでの WCAG の適合要件、たとえば適切なコントラストであること、特定できる名前を持つこと、キーボードによるアクセスが可能であることに合致する。コントロールはページの先頭か、動きのあるコンテンツの近くに配置する。動きのあるコンテンツ又は点滅するコンテンツのすべてを一つのコントロールで停止できるか、コンテンツの別々の部分を別々のコントロールで停止できればよい。

事例

事例 1: 株式市場のティッカーテープ

あるウェブページに、株式市場の最新結果を表示する「ティッカーテープ」があり、画面の下に向かって自動スクロールする。利用者は「一時停止」ボタンでティッカーテープの動きを停止させることができる。一時停止を解除すれば、現在の株式市場の情報表示を再開する。

事例 2: 電子会議ツール

電子会議用のウェブページに、発言待ちのスピーカーの一覧がある。利用者は、新しい人が加わったり外れたりするときに一覧を自動更新するか、それとも「更新」ボタンを押したときにだけ更新するかを、ページ上のチェックボックスで選択できる。一覧が自動更新に設定されている場合、更新ボタンは非活性になっている。

検証

手順

コンテンツの動き、点滅、自動更新を停止させるコントロールがウェブページ上にあることを確認する。
そのコントロールを有効にする。
コンテンツの動き、点滅、自動更新が停止することを確認する。

期待される結果

1. 及び 3. の結果が真である。

G187: ユーザエージェントによって点滅するコンテンツを停止できるウェブコンテンツ技術を使用する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.2 (一時停止、停止、非表示)
- クイックリファレンス 2.2.2 (一時停止、停止、非表示)
- 達成基準 2.2.2 (一時停止、停止、非表示)を理解する

解説

この達成方法の目的は、点滅するコンテンツをユーザエージェントの機能を使用して止めることができるようにすることである。特定のウェブコンテンツ技術では、ユーザエージェントによって利用者がアニメーションを止めることができる。利用者がこの機能を実行するとき、点滅も含めたすべてのアニメーションは停止する。この機能は、WCAG に適合したインタラクティブなコントロール、又は明記されたキーボードショートカットのいずれかによって提供することが可能である。

利用者がアニメーションを止めるための一般的な方法は、Esc キーを押すことである。そのキーを押すためのイベントキューの中で先行するプロセスがない限り、動きのあるアニメーションや点滅しているコンテンツを停止するコマンドとして動作する。

一般的にこれが機能するとされているウェブコンテンツ技術:

Graphics Interchange Format (GIF)
Animated Portable Network Graphics (APNG)

訳注: WAIC では G187 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: G187 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例

ページに、利用者の注意をひきつけるための点滅するバナーがある。そのバナーは無制限に繰り返すアニメーション GIF である。利用者は Esc キーを押すことによって、ページ上のすべてのアニメーション GIF の動きを止めることができる。

検証

手順

点滅するコンテンツを含むページを読み込む。
ブラウザのアニメーションを止めるコマンドを実行する。(通常は、Esc キー)
点滅が止まっているかどうかを確認する。

期待される結果

3.の結果が真である。

G188: 行間及び段落の間隔を広げるボタンをウェブページ上に提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.8 (視覚的提示)
- クイックリファレンス 1.4.8 (視覚的提示)
- 達成基準 1.4.8 (視覚的提示)を理解する

解説

多くの認知障害を持つ人々は行間がシングルスペースに設定されたテキストを読む事が困難である。行の高さを増やすボタンは彼らが内容を読む助けとなる。段落の間が離れている状態を維持するためには、段落間の幅は、行送り幅の少なくとも 1.5 倍の高さになるように広げられるべきである。

注記: この達成方法は、不適合コンテンツに対して、適合している代替版のページを提供するための、スタイルスイッチの達成方法と組み合わせて用いることができる。詳細は、C29: 適合している代替版を提供するために、スタイルスイッチャーを使用する (CSS) 、及び適合している代替版を理解するを参照のこと。

事例

事例 1

ページを変更するための標準的なスタイルスイッチングを用いる。スタイルシートを切り替えるためのボタン又はリンクをページに用意する。新しいスタイルシートには、行送りを広げるルールと段落の間隔を広げるクラスが含まれている。

コード例:


        p {line-height: 150%; margin-bottom: 2em;}

参考リソース

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

Developing sites for users with Cognitive disabilities and learning difficulties

検証

手順

ページ内に行送り及び段落の間隔を広げるためのボタン又はリンクがあり、そのことがわかるようにラベルづけされている。
そのボタン又はリンクを起動する。
ボタン又はリンクによって、行送りが少なくとも 1.5 (150%) に広がることを確認する。
ボタン又はリンクによって、各段落の間隔が行送りの少なくとも 1.5 倍より広くなることを確認する。

期待される結果

1.、3. 及び 4. の結果が真である。

G189: ウェブページの先頭近くに、リンクテキストを変更するコントロールを提供する

適用 (対象)

リンクを実装できる全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、ウェブページの先頭近くに、そのウェブページの適合している代替版へ利用者を誘導するコントロールを提供することである。その代替版では、各リンクのリンクテキストだけで前後の文脈を見なくてもリンクの目的がわかるようになっている。

利用者の中には、リンクの文脈を見なくても、リンクの目的がわかるのでリンクテキストにその文脈も含んだリンクを好む利用者がいる。一方で、文脈の情報を各リンクに含めることでリンクテキストが冗長になるため、サイトの使い勝手が悪くなると感じる利用者もいる。WCAG ワーキンググループに支援技術の利用者から寄せられたフィードバックでも、どちらを好むかは意見が分かれている。この達成方法を用いることにより、利用者は、自分にとって最適なアプローチを選べるようになる。長くなる可能性があっても完全なリンクテキストを必要とする又はそれを好む利用者は、代替版を使用することができる。

代替版に変換するコントロールがリンクである場合、そのコントロールの目的が、常にリンクテキストだけでわかるようにしておかなければならない。

この達成方法は、現在のページ表示に対する代替版を提供する。この環境設定をクッキー又はサーバーサイドのユーザプロフィールに保存して、利用者が一度選択すれば、その後はサイトを訪れるごとに選択しなくても、自動的に利用者の好むバージョンが表示されるようにすることもでき、そうするのが望ましい場合もある。

注記: この達成方法は、表示スタイルを変更して不適合コンテンツに対する適合した代替版となるページを提供する達成方法と併せて使うことができる。詳しくは、C29: 適合している代替版を提供するために、スタイルスイッチャーを使用する (CSS) 及び適合している代替版を参照のこと。

事例

事例 1: 別バージョンへのリンクを提供する

ウェブページに、様々なフォーマットでダウンロードできる書籍のリストがある。このウェブページの代替版では、書籍のフォーマットだけ、又は書籍名とフォーマットのタイプが、リンクテキストとして使われている。

短いリンクテキストのバージョン:

コード例:


              ...
                <h1>Books for download</h1>
                <p><a href="books-full-links.html" >Full link Version</a></p>
                <ul>
                <li>The History of the Web: 
                <a href="history.docx" class="hist">Word</a>, 
                <a href="history.pdf" class="hist">PDF</a>, 
                <a href="history.html" class="hist">HTML</a>
                </li>
                ...
                </ul>

完全なリンクテキストを用いたバージョン:

コード例:


              ...
                <h1>Books for download</h1>
                <p><a href="books-short-links.html" >Short link Version</a></p>
                <ul>
                <li>The History of the Web: 
                <a href="history.docx" class="hist">The History of the Web(Word)</a>, 
                <a href="history.pdf" class="hist">The History of the Web(PDF)>/a>, 
                <a href="history.html" class="hist">The History of the Web(HTML)</a>
                </li>
                ...
                </ul>

検証

手順

ウェブページの先頭近くに、リンクテキストを変換するコントロールがあることを確認する。
コントロールを起動する。
得られるウェブページで、全てのリンクにその目的を説明しているリンクテキストがあることを確認する。

期待される結果

1. 及び 3. の結果が真である。

G190: 適合している代替版へのリンクを、不適合のオブジェクトに隣接して、又は関連付けて提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

適合要件 1 (適合レベル)

解説

ページにあるすべてのオブジェクトが適合しているのがより望ましいが、それが可能ではない状況もある。オブジェクト又はコンテンツのセクションが特定の障害のある利用者を想定していると、一方でそういった同じ属性が他の利用者にとってアクセシブルではなくなるという状況がありえる。また、ウェブページ上に適合しているオブジェクトを持たない他の理由も考えられる。オブジェクトが適合していない際には、適合している代替版へのリンクが線形化した読み上げ順序の中で適合していないオブジェクトに隣接している、又は適合していないコンテンツと関連付けられている。適合している代替版は、適合していないバージョンと同じ情報を伝達している。

事例

事例 1: 音楽の芸術的な品位を阻害する音声解説のあるラップ音楽映像

「ヒップホップキッド」という名前のラップ音楽の映像には背景音がある。音声解説を歌の合い間に挿入することは、アーティストが伝えようとしているギターとドラムの最高潮の演奏を妨げるであろう。そのウェブページ上では、映像オブジェクトのすぐ次に「"ヒップホップキッド"の音声解説バージョン」というリンクがあり、映像の中で視覚的に何が起きているかという音声解説を含んでいるバージョンが提供されている。

事例 2: 歴史文書の画像

独立宣言についてのウェブページに、文書の画像がある。テキストと背景の間のコントラストは不十分であり、手書きの文書は読むことが困難である。利用者をその文書の HTML バージョンへ誘導するリンクがある。

事例 3: アクセシビリティサポーテッドではないアニメーション

アクセシビリティサポーテッドではないウェブコンテンツ技術を使用して制作されたインタラクティブなアニメーションがウェブページ上で表示されている。アニメーションの適合している代替版へのリンクは、適合していないコンテンツに隣接している。

G136: 不適合なウェブページの先頭に、適合している代替版を指すリンクを提供する

検証

手順

ページ内の適合していないオブジェクトそれぞれに対して:

ウェブページ上に適合していないオブジェクトがあるかどうかを確認する。
線形の読み上げ順序で、適合していないオブジェクトの直後に、オブジェクトの特定可能な適合しているバージョンへのリンクがあるかどうかを確認する。
そのリンク先に適合しているバージョンがあるかどうかを確認する。

期待される結果

2. 及び 3. の結果が真である。

G191: 点滅するコンテンツのないページを再読み込みするリンク、ボタン、又はその他のメカニズムを提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.2 (一時停止、停止、非表示)
- クイックリファレンス 2.2.2 (一時停止、停止、非表示)
- 達成基準 2.2.2 (一時停止、停止、非表示)を理解する

解説

この達成方法の目的は、ウェブページに点滅するコンテンツがあると閲覧できない利用者が点滅をオフにできるようにすることである。適合要件 1 では、代替ページを使用することによって適合要件を満たすことが認められている。この達成方法は、達成基準 2.2.2 に対してこのアプローチを取った例である。

点滅するコンテンツのないページが、点滅するコンテンツのあるページと全く同じ情報を提供していることが重要である。

注記 1: ウェブページから点滅するコンテンツを取り除くことは、そのコンテンツが点滅しないコンテンツと重複している場合にのみ有効である。

注記 2: この達成方法は、表示スタイルを変更して不適合コンテンツに対する適合している代替版となるページを提供する達成方法と併せて用いることができる。詳しくは、C29: 適合している代替版を提供するために、スタイルスイッチャーを使用する (CSS) 及び適合している代替版を理解するを参照のこと。

事例

ページの上部には初回登録なしでページを送信すべきでないことを警告する点滅するテキストがある。ページの最上部にあるリンクはページを再読み込みし、点滅するテキストは、よく目に見えるようにスタイル付けされるが点滅しないテキストに置き換えられる。

検証

手順

点滅をオフにするためのページを再読み込みするメカニズムがあることを確認する。
再読み込みしたページには点滅がないことを確認する。
再読み込みしたページでは、元のページにある情報及び機能があることを確認する。

期待される結果

上記の全ての結果が真である。

G192: 仕様に完全に準拠する

適用 (対象)

この達成方法は仕様のある全てのマークアップ言語に関連する

これは、次の達成基準に関連する達成方法である:

達成基準 4.1.1 (構文解析)
- クイックリファレンス 4.1.1 (構文解析)
- 達成基準 4.1.1 (構文解析)を理解する

解説

マークアップ言語がその仕様に完全に準拠していれば、4.1.1 のすべての要件が満たされる。つまり、仕様に完全に準拠することは、WCAG 2.0 に適合するために必要ではないが、成功事例であり、達成基準 4.1.1 を満たすことになる。

事例

あるページは、全てのウェブコンテンツ技術が、仕様に従って使用されるよう慎重に作成されている。バリデーターを使用し、発見されたすべての誤りは修正されている。また、バリデーションで発見できない仕様の要求事項もまたチェックされ、すべての不具合は修正されている。

検証

手順

全てのウェブコンテンツ技術が仕様に従って使用されることを確認する。

注記: バリデータは、誤りを見つけるための優れたツールであるが、通常、コンテンツが仕様に対して完全に準拠となっていない事例の全てを見つけられるものではない。

期待される結果

1. の結果が真である。

G193: ウェブページでアシスタントによるヘルプを提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 3.3.5 (ヘルプ)
- クイックリファレンス 3.3.5 (ヘルプ)
- 達成基準 3.3.5 (ヘルプ)を理解する

解説

この達成方法の目的は、ウェブページを利用する際の支援となるマルチメディアのアバターを使ったヘルプを提供することである。アバターを使ったヘルプは、テキストを読むことが難しい認知障害のある利用者に特に役立つ。また、視覚情報を利用することで、提示された題材に集中するのに役立つことがある。

注記: マルチメディアのアバターはガイドライン 1.2 の関連する達成基準も満たさなければならない。

事例

オンライン銀行アプリケーションのホームページには、ヴァンナという名前のアバターが組み込まれている。彼女はオンライン銀行の新規顧客にアプリケーションで提供している機能について紹介するツアーを行っている。利用者は、アシスタントによるツアーを始めたり、中止したり、一時停止したりすることができ、また、コンテンツを巻き戻したり、先に送ったりすることができる。アバターの隣のリンクからそのツアー情報の代替テキストが利用できる。
ボランティアサイトに新しいボランティアを迎えるページがある。その中には申込フォームがある。ページの右には、アバターが登場して情報のやり取りをするマルチメディアファイルがあり、申込書の全ての機能及びセクションの説明をする。

検証

手順

ウェブページにアシスタント機能があることを確認する。
アシスタントはそのページの内容の理解を手助けする情報を提供していることを確認する。

期待される結果

上記の全ての結果が真である。

G194: テキスト入力に対するスペルチェック及び修正候補を提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 3.3.5 (ヘルプ)
- クイックリファレンス 3.3.5 (ヘルプ)
- 達成基準 3.3.5 (ヘルプ)を理解する

解説

この達成方法では、スペルチェック機能やテキストの入力候補の提供について示している。認知障害のある利用者の場合、単語のおよその綴りは分かっても、正しく綴ることが難しいということがしばしばある。スペルチェックプログラムを用いることで、単語の正しい綴りを調べるという時間のかかる作業を行わなくてもよくなる。これは、視覚障害のある利用者でミスタイプが多い場合にも有効である。また、手に障害があり、額に装着する形のポインティングデバイスを使用していたり、スキャンソフトウェアでオンスクリーンキーボードを使用している、入力が困難で時間のかかる利用者にとっても有効である。入力単語の候補を提示し、簡単な仕組みで入力したい単語を選択することでテキストフィールドに入力できるような機能を持つスペルチェック機能は、こういった利用者にとって有効である。

事例

ある検索エンジンには、検索語を入力するためのフォームフィールドがある。フォームが送信されると、サーバーサイドのアプリケーションがスペルチェックを行う。もし、その言語に綴りが一致する単語がない場合は、ページの冒頭で「もしかして……」というテキストのメッセージとともに検索語の候補となる単語がリンクになった形のページを送信する。利用者がこれらのリンクをクリックした場合は、その入力候補がフォームに入力された状態で、フォームが再送信される。
ある航空会社は、オンラインで航空券を購入できるアプリケーションを提供している。利用者がフォームフィールドに都市名を入力すると、入力内容に最も近い都市名が一番上にあり、それ以外の候補がその下に続くようなドロップダウンメニューが表示される。

検証

手順

ウェブページにフォームフィールドがあることを確認する。
綴りが誤っている単語を入力する。
単語の修正候補が提示されることを確認する。
提示された修正候補をフォームに入力するメカニズムがあることを確認する。

期待される結果

3. 及び 4. の結果が真である。

G195: コンテンツ制作者が提供する視認性に優れたフォーカスインジケータを使用する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.7 (フォーカスの可視化)
- クイックリファレンス 2.4.7 (フォーカスの可視化)
- 達成基準 2.4.7 (フォーカスの可視化)を理解する

解説

この達成方法の目的は、視認性に優れたフォーカスを作ることによりブラウザのフォーカスインジケータを強調することである。多くのブラウザにおける初期値のフォーカスインジケータは、細いドットの黒い線になっている。アウトラインを既に持っているようなフォーム要素を囲っている場合、テーブルセルの中にフォーカス要素が入っている場合、フォーカスされた要素がとても小さい場合、もしくはページの背景の色が濃い色の場合は、そのフォーカスを見ることが困難である。

この達成方法において、利用者がマウス、Tab キー、矢印キー、キーボードのショートカット、もしくは他の方法を用いて要素にフォーカスを置いている時、アプリケーションは高いコントラスト比を持った色、太字、そして光を放つような視覚的インジケータを用いることによってフォーカスをより視認性のあるものにしている。

事例

事例 1: リンク

濃い背景色と明るい文字とリンクを持つウェブページがある。フォーカスがリンクにあたると、そのリンクは 3 ピクセルの明るい黄色のラインで囲まれる。

事例 2: フォーム要素

テーブルの中にフォームが書かれているウェブページがある。テーブルとフォームの要素の両方の境界は細くて黒い線になっている。フォーカスがフォーム要素に当たる時、その要素は部分的に透明になっている 5 ピクセルの赤い線で囲まれる。

事例 3: メニュー

サブメニューを持ったインタラクティブなメニューを含んだウェブページがある。利用者は矢印キーを使ってメニューの中でフォーカスを動かすことができる。フォーカスが動くと、フォーカスが当たっているメニュー項目はその背景を異なる色に変える。その色は周りの項目に対して 3:1 のコントラスト比を持ち、そのメニューのテキストの色と 4.5:1 のコントラスト比を持っている。

検証

手順

マウスを用いてページ上のそれぞれのフォーカスできるユーザインタフェース要素にフォーカスを置く。
視認性に優れたフォーカスインジケータがあることを確認する。
キーボードを用いてページ上のそれぞれのフォーカスできるユーザインタフェース要素にフォーカスを置く。
視認性に優れたフォーカスインジケータがあることを確認する。

期待される結果

2.及び 4.の結果が真である。

G196: 画像のグループにある一つの画像に、そのグループのすべての画像を説明するテキストによる代替を提供する

適用 (対象)

非テキストコンテンツのグループを用いて情報又は機能を提示する、全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

解説

この達成方法の目的は、隣り合う非テキストコンテンツのグループを用いて情報又は機能を提示する際に生じる不要な重複を回避することである。

ウェブページでは、画像のグループを提示して情報を伝えることがある。一緒に提示する、又は特定の組み合わせで提示することにより、こうしたグループは様々なタイプの情報を伝えることができる。例えば、二つの星の画像のうち一つを白黒、もう一つをカラーで表示し、利用者評価を表すために使用することができる。また、塗りつぶした三つの星に続いて塗りつぶしていない二つの星を提示すれば、利用者評価が満点の五つ星のうちの三つ星であることを示すこともできる。

この達成方法を用いるには、コンテンツ制作者が、グループ全体と等価の目的を果たすテキストによる代替をそのグループにあるどれか一つのアイテムに関連付けて提供する。そして、グループ内のその他のアイテムは、支援技術が無視できるようにする。こうすることによって、利用者は、より効率的にそのグループの目的を理解して、グループ内の各アイテムにテキストによる代替が提供した際に生じる重複又は混乱を回避することができる。

事例

事例 1: HTML での評価システム

次の例では、塗りつぶされた星三つと塗りつぶされていない星二つで評価が示されている。テキストによる代替は、五つの画像それぞれに提供することもできるが、このコンテンツ制作者は、一つ目の画像に「3 out of 5 stars」として画像のグループが伝えている評価を提供し、他の画像には空の代替テキストを用いている。

コード例:


              <p>Rating: 
                <img src="star1" alt="3 out of 5 stars">
                <img src="star1" alt="">
                <img src="star1" alt="">
                <img src="star2" alt="">
                <img src="star2" alt="">
                </p>

訳注: WAIC では G196-1 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: G196-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2: XHTML で画像のグループによって作成されたボタン

この例では、宣言している WCAG への適合レベルを示すために、各ボタンが複数の画像一式を用いている。このアプローチによって、支援技術は「画像 A、画像 A、画像 A」などのように読み上げるのを回避できるようになる。

コード例:


              <p>Conformance Level:</p>
                <button name="A"><img src="a.png" alt="A" /></button> <br />
                <button name="AA"><img src="a.png" alt="AA" /><img src="a.png" alt="" /></button> <br />
                <button name="AAA"><img src="a.png" alt="AAA" /><img src="a.png" alt="" /><img src="a.png" alt="" /></button>

訳注: WAIC では G196-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: G196-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

検証

手順

グループ内の一つのアイテムに、そのグループ全体の目的と等価なテキストによる代替があることを確認する。
グループ内のその他のアイテムが、支援技術が無視できるようにマークされていることを確認する。
支援技術が無視できるようにマークされたアイテムが、グループ全体に対するテキストによる代替のあるアイテムと隣り合っていることを確認する。

期待される結果

上記全ての結果が真である。

G197: 同じ機能を有するコンテンツに対して、一貫したラベル、名前 (name) 及びテキストによる代替を使用する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 3.2.4 (一貫した識別性)
- クイックリファレンス 3.2.4 (一貫した識別性)
- 達成基準 3.2.4 (一貫した識別性)を理解する
注記: この達成方法は、達成基準 3.2.4 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 3.2.4 を理解するを参照すること。

解説

この達成方法の目的は、認識障害、全盲もしくは弱視の利用者に対して、ウェブページ内の機能にインタラクトしたときに何が起こるかを理解するのを助けることである。同じ機能を提供するユーザインターフェースコンポーネント (要素、リンク、JavaScript オブジェクトなど) に異なるラベルが付けられていると、利用者は同じ機能を持つコンポーネントに出会ったことに気づかず、何が起きるかを予測することができないだろう。これがたくさんの無用な操作ミスにつながるかもしれない。加えて、一貫したラベル付けに関するこのようなアプローチはウェブサイト全体に対して適用することを推奨する。

事例

あるウェブページには冒頭に「検索」とラベル付けされたフォームフィールドがある。ページの最後にも同じ機能を果たすフォームフィールドがあり、そのフォームフィールドもまた「検索」とラベル付けされている。
追加の情報が記載されたページ中のセクションに利用者を誘導するため、疑問符の画像が用いられている。疑問符の画像が現れる個所すべてにおいて、同一の「詳細情報」という代替テキストが付けられている。
あるウェブサイトでは問い合わせページへのリンクには「問い合わせ」というリンクテキストが付けられている。ページ最下部にも問い合わせページへのリンクが設けられている。このリンクのリンクテキストも「問い合わせ」となっている。

検証

手順

各コンポーネントがそれを特定できるテキスト (ラベル、名前 (name)、又はテキストによる代替) に関連付けられていることを確認する。
この関連付けられているテキストが、同じ機能を提供する各ユーザインタフェースコンポーネントに関して同一であることを確認する。

期待される結果

1. 及び 2. の結果が真である。

G198: 利用者が制限時間を解除するための手段を提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.1 (タイミング調整可能)
- クイックリファレンス 2.2.1 (タイミング調整可能)
- 達成基準 2.2.1 (タイミング調整可能)を理解する

解説

この達成方法の目的は、指定された制限時間内にタスクを完了できない利用者に対して、制限時間を解除するメカニズムを提供することである。

制限時間を解除するメカニズム自体に制限時間が設けられておらず、またウェブページ全体の制限時間前に完了できるようにすることが非常に重要である。そのためには、さまざまな障害のある利用者がすばやく見つけて解除できるように、このメカニズムをページの上部又は上部近くで提供すべきである。

事例

ウェブページに、毎分自動更新されるニュースの見出しのリストが表示されている。このページの上部に、更新をオフにするリンクがある。

検証

手順

ウェブページの上部近くに、あらゆる制限時間を解除するメカニズムがあることを確認する。
ウェブページの制限時間が、一般的な利用者よりも 10 倍の時間を要する利用者でも、そのメカニズムを利用できるのに十分な長さであることを確認する。

期待される結果

1. 及び 2. の結果が真である。

G199: データが正常に送信されたときに、フィードバックを提供する

適用 (対象)

利用者のデータインプットを受け入れているコンテンツ

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、利用者にアクションを確認させる手間 (例えば、ウェブフォームを送信した時に、それが正常に完遂されたことを利用者に確認させる) をなくすことである。アクションが成功したかを確認させるように促す代わりに、アクションが成功したか明確に示すフィードバックを常に提供することで達成することができる。

アクションを確認するために、情報に目を通すことが容易ではない利用者の大きな手間が費やされる時がある (例えば、データベースにデータが正常に送信されたか、人に送られたのか、または編集されているコンテンツに追加されたのか)。

事例

利用者がシステムにログインする際、応答として「正常にログインできました」と表示される。そのため、利用者はログインできたかどうかを知るための手がかりとして、利用者名があるか、ログインリンクがログアウトリンクに変わったか、などを探して画面中を見てまわる必要がない。それらを探すことは、時間の浪費となる可能性がある。
利用者がクイズやテストを送信する。応答において、テストが正常に送信されたと知らせている。そのため、利用者は送信が正常に行われたかを確認するために、送信されたテストのリストなどを探し回る必要がない。
訪問者がウェブサイトでアカウントを作る。フォームを送信した後に、「登録が正常に送信されました……」とフィードバックされる。もし登録の後に自動的にログインするのであれば、フィードバックに「……ログインしました。」と追記される。もし確認が必要である場合、フィードバックは「……登録の確認を求める E メールを送信しました」と続く。
利用者がサポートスタッフに直接充てた情報をフォームで送信する。フィードバックは「メッセージは正常に送信されました。48 時間以内に回答が届きます。」と示す。

検証

手順

エラーがないようにフォームフィールドに入力する。
フォームを送信する。
正常に送信できたことが、画面上にフィードバックメッセージとして確認する。

期待される結果

3. の結果が真である。

G200: 必要なときにのみリンク先を新しいウィンドウ及びタブで開く

適用 (対象)

新しいウィンドウを開くウェブページ

これは、次の達成基準に関連する達成方法である:

ガイドライン 3.2 (予測可能)を理解する

解説

この達成方法の目的は、ウェブコンテンツ内で新しいウィンドウまたはタブを開くリンクまたはボタンの使用を限定することである。一般的に、新しいウィンドウやタブを開かないほうがよい。なぜなら、特に視覚的なコンテンツを知覚するのに困難を伴う利用者をはじめ、利用者にとっては混乱の原因となりうるからである。しかし、アクセシビリティの観点から、新しいウィンドウやタブを開くことが望ましい状況というのもある。例えば、次の二つのような場合である:

例えば、ヘルプの説明文またはカレンダーを用いたデートピッカー (日付選択) のようなフォーム入力の代替手段のように、状況に応じた情報を含むウェブページを開く際に、もしそういったウェブページが同じウィンドウやタブで開かれるとしたら、フォームを入力したり送信したりするような複数のステップから成るワークフローを著しく中断させることになる。
利用者がセキュアなサイトにログインしていて、そのサイト外にあるページへのリンクをたどっていくとログインした状態が打ち切られてしまう。この場合、外部へのリンクを別のウィンドウで開くことによって、利用者は元のウィンドウでログインした状態を保ちながら関連するリソースにアクセスすることができるようになる。

リンク先のウェブページが新しいウィンドウで開かれる際には、利用者に事前に知らせることが推奨される。

事例

事例 1: オンラインフォーム

各入力項目に対する状況に応じたヘルプをフォーム上で提供するには文字量が多すぎるため、別のウェブページで提供しているオンラインフォームがある。すでに入力済みのフォームデータが失われないように、状況に応じたヘルプへのリンクは新しいウィンドウまたはタブを開くようになっている。

事例 2: セキュアなウェブサイト

セキュアなウェブサイト内のあるウェブページにセキュアなセッション外にあるウェブページへのリンクがある。そのリンクを同じウィンドウで開くとセキュアなセッションが無効になってしまうため、新しいウィンドウまたはタブで開くようになっている。

事例 3: デートピッカー (日付選択)

オンラインフォームに日付のフィールドがあり、利用者は日付を入力するか、別ページのカレンダーを用いたデートピッカーから日付を選択することができるようになっている。すでに入力済みのフォームデータが失われないように、カレンダーを用いたデートピッカーへのリンクは新しいウィンドウまたはタブを開くようになっている。

参考リソース

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

Beware of opening links in a new window

Top-10 New Mistakes of Web Design

G201: 新しいウィンドウを開くときに、利用者へ事前に知らせる

適用 (対象)

新しいウィンドウを開くウェブページ

これは、次の達成基準に関連する達成方法である:

ガイドライン 3.2 (予測可能)を理解する

解説

この達成方法の目的は、自動的に新しいウィンドウまたはタブを開く前に利用者に知らせることである。リンクを動作させたときに自動的に新しいウィンドウを開くことは、もし事前にそのことを知らせていなければ、視覚的なコンテンツを知覚するのに困難を伴う利用者や認知障害のある利用者が混乱する原因となりうる。事前に知らせることによって、利用者は現在のウィンドウから離れるかどうかを判断することができるようになる。また、利用者が新しいウィンドウを開くことを選んだ場合にも、元のウィンドウに戻りやすくなる。さらに、ブラウザの [戻る] ボタンが使えないことや、直前まで自分がいた場所を見つけるためには元のウィンドウに戻らなければならないことを利用者が理解する手助けにもなる。

事例

事例 1: コントロールを説明するテキストで知らせる

コントロールを説明する名前 (name) またはラベルを用いて、新しいウィンドウで開くことを知らせることができる。

コード例:


              <a href="knitting.html" target="_blank">All about Knitting 
                (opens in new window)</a>

事例 2: CSS を用いて、新しいウィンドウが開く前に知らせる

以下のコードでは、CSS を用いて新しいウィンドウが開く前に知らせている。

コード例:


              <html>
                <head>
                <title>Pop-Up Warning</title>
                <style type="text/css">
                body {
                margin-left:2em;
                margin-right:2em;
                }
                :focus { outline: 0; }
                a.info {
                position:relative;
                z-index:24;
                background-color:#ccc;
                color:#000;
                text-decoration:none
                }
                a.info:hover, a.info:focus, a.info:active {
                z-index:25;
                background-color:#ff0
                }
                a.info span {
                position: absolute;
                left: -9000px;
                width: 0;
                overflow: hidden;
                }
                a.info:hover span, a.info:focus span, a.info:active span {
                display:block;
                position:absolute;
                top:1em; left:1em; width:12em;
                border:1px solid #0cf;
                background-color:#cff;
                color:#000;
                text-align: center
                }
                div.example {
                margin-left: 5em;
                }
                </style>
                </head>
                <body>
                <h1>Pop-Up Warning</h1>
                <p> This is an example of an <a class="info"
                href="popup_advisory_technique.html" target="_blank">
                <strong>External link</strong><span>Opens a new
                window</span></a>
                </p>
                </body>
                </html>

参考: CSS を用いて、新しいウィンドウが開く前に知らせるサンプル: 英語

検証

手順

利用者の要求によるコンテキストの変化が生じたときに自動的に新しいウィンドウ又はタブで開くリンクに対して:

このリンクを新しいウィンドウで開くことが支援技術で読み上げられることを確認する。
このリンクを新しいウィンドウで開くことが視覚的に示されていることを確認する。

期待される結果

1. 及び 2. の結果が真である。

G202: すべての機能に対してキーボード制御を確保する

適用 (対象)

インタフェース操作をサポートするウェブコンテンツ技術すべて

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、ウェブページのすべての機能をキーボードで操作可能にすることである。ウェブコンテンツのすべての機能がキーボードまたはキーボードインタフェースによって操作可能であれば、全盲の利用者や代替キーボード、音声入力ソフトウェアやオンスクリーンキーボードのようなキーボードエミュレータとよばれる入力デバイスを使用しなければならない利用者が操作できることになる。

たとえ使用している計算装置がハードウェアキーボードを含んでいなくても、キーボードインタフェースは、利用者がプログラムにキーストローク入力を提供することを可能にする。例えば、多くのモバイルデバイスはオペレーティングシステムにキーボードインタフェースか、又は外部接続のワイヤレスキーボードに接続する選択肢を持っている。アプリケーションは、外部接続のキーボードまたは他の模擬的にキーボードアウトプットができるサービスからキーボードインプットを得るインターフェースを使える。例えば、スイッチデバイス、手書き解釈プログラムまたは書き起こしアプリケーションなどがある。

この達成方法を用いるには、まずそのウェブページでどのような機能が利用者に提供されているのかを確認する必要がある。その際には、マウスやキーボードを使って使用する機能を特定することが重要である。そういった機能の例としては、リンク、メニュー、ボタン、チェックボックス、ラジオボタン、フォームフィールドのような操作系のものや、ドラッグ＆ドロップ、テキスト選択、領域のサイズ変更、コンテキストメニューの表示のような機能的なものが挙げられる。他にも、ショッピングカートでのアイテムの追加や削除、販売担当者とのチャットの起動などのように、タスクをベースにした機能が例として挙げられる。

ウェブコンテンツが提供している機能を確認したら、コンテンツ制作者はそれぞれの機能がキーボードだけでも操作することが可能かどうかを検証する。

注記: 同じ機能を使用できる手段がウェブページ上で複数提供されている場合には、必ずしもそれぞれのコントロールをキーボードだけで操作可能にする必要はない。その場合、コンテンツ制作者には、利用者がキーボードで操作可能な手段を見つけやすくすることが推奨される。

事例

利用者がマウスオーバーすると変化するリンク画像のあるウェブページがある。キーボード利用者に対して同様の体験を提供するために、利用者がキーボード操作でフォーカスをそのリンク画像に移動させたときにも画像が変化するようにしている。
リストにあるアイテムをクリックしてドラッグすると順序を入れ替えることができるウェブページで、キーボード操作でリスト内のアイテムの順序を前後に移動させたり、リストの先頭や最後に移動させたりすることのできるコントロール一式も提供している。
モバイル版ウェブサイトに、タップするとフロートオーバーレイでサイトメニューを開くメニューボタンがある。モバイルデバイスに接続する外部接続キーボードまたは特殊スイッチを利用している人々へのアクセスを提供するために、メニューボタン及びサイトメニューがいずれもモバイルデバイスのキーボードインタフェースで操作できるようにしている。

G90: キーボードがトリガーとなるイベントハンドラを提供する

検証

手順

ウェブコンテンツの全ての機能を特定する。
キーボードのみ、又はキーボードインタフェースのみで全ての機能にアクセスが可能であることを確認する。

期待される結果

2. の結果が真である。

G203: 話者が話すのみの映像を説明するために、静的なテキストによる代替を使用する

適用 (対象)

話者が話すのみの映像

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、メディアの映像部分に含まれる重要な時間依存の情報を持たない、同期したメディアの音声解説に対する代替を提供することである。これは、特に、記者会見や社長の会見、政府の公式発表などの変化しない背景の前で話している「話者の顔」の映像を指す。この場合、音声解説が保障するであろう「重要な視覚的詳細」はない。

一人の人物が変化しない背景の前で話している場合は、音声解説は必ずしも必要ない。なぜなら、この映像には、内容を理解するために「重要」な時間依存の視覚的情報がないためである。周囲の状況が変化しないため、映像にプログラム的に関連付けられた代替テキストのような、マルチメディアではない静的なフォーマットで記述できる。

この場合、静的なテキストによる代替を用意し、周囲の状況や文脈の説明、オープニング/クロージングクレジット、話者の名前、その他基本的な情報など、画面に映りながら音声として聞くことができないものの一般的な解説をすれば足りる。

この達成方法は、複数の話者がおり、音声ではそれぞれの新しい話者が明確でないが、視覚的なテキストで明確にされているような状況では適用されない。その場合は音声解説を用いるべきであり、この達成方法は適用されない。

事例

事例 1: 株主に語りかけている CEO の映像

CEO がオフィスで株主に語りかけている。この映像の冒頭には、日付の入ったタイトルカットがある。話が始まると、映像の下部に「XYZ 社社長 John Doe」とテキストが出てくる。映像の最後には「制作 Honest TV Productions Ltd.」とタイトルクレジットが出てくる。

代替として、映像の下に aria-describedby 属性で映像ファイルと関連づけられた段落があり、「6 月 22 日 John Doe XYZ 社社長オフィスにて撮影。Honest TV Productions Ltd. 制作」と書かれている。

検証

手順

映像トラックの中に時間依存の重要な情報がない。
そのメディアにプログラムで関連付けられた解説が、音声に含まれていない内容の文脈を説明している (例えば、話者の紹介、クレジット、文脈など) ことを確認する。

期待される結果

全ての結果が真である。

G204: 閲覧画面の幅を狭めたときに、ユーザエージェントによるテキストのリフローを妨げない

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.8 (視覚的提示)
- クイックリファレンス 1.4.8 (視覚的提示)
- 達成基準 1.4.8 (視覚的提示)を理解する

解説

この達成方法は、横スクロールが起こる状況を回避することを助けるものである。ブロックやテキストの横スクロールは、支援技術を用いていない認識障害がある人々やロービジョンの利用者にとっては大きな問題となる。ウィンドウ幅が狭い時にテキストのリフローを妨げないことも含まれる。最善の方法のひとつは、テキストブロックコンテナの横幅をパーセントで定義することである。

制作者が横幅をピクセルやポイントなどの絶対値で定義していない限り、ウィンドウ幅が狭い時、HTML 及び XHTML ユーザエージェントは自動的にテキストをリフローする。

事例

事例 1

新聞社のサイトがユーザエージェントのウィンドウ幅に合わせたカラム数の記事を含んでいる。認知障害の利用者は、読みやすいようにカラムを狭めることができる。

参考リソース

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

CSS Box Model

訳注: CSS2 の「CSS Box Model」は、CSS Box Model Module Level 3 で再定義されている。

C20: ブラウザがサイズ変更されるときに、行が平均で 80 字以下になるようなカラムの幅を設定するために、相対長さを使用する

検証

手順

一般的なユーザエージェントで、テキストブロックを含むコンテンツを開く。
ユーザエージェントにリフローを許可する設定があるか確認し、もしあれば有効にする。
ウィンドウ幅をスクリーン幅の 1/4 に縮める。
1 行の文章を読むために、コンテンツを横スクロールする必要がないことを確認する。

期待される結果

4. の結果が真である。

G205: 色のついたフォームコントロールのラベルに対して、テキストによる手がかりを含める

適用 (対象)

色とテキストをサポートするすべてのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.1 (色の使用)
- クイックリファレンス 1.4.1 (色の使用)
- 達成基準 1.4.1 (色の使用)を理解する

解説

この達成方法の目的は、情報を伝えるために、色と、テキスト又は文字による手がかりを併用することである。ほとんどの利用者は色の差を用いた情報を素早く認識できる。色を識別できない利用者は、視覚的又は聴覚的にテキストによる手がかりを認識する。点字ディスプレイや、他の触覚インタフェースを使っている人々は触ることでテキストによる手がかりを見つけられる。

テキストによる手がかりは、フォームコントロールの、プログラムによる解釈が可能な名前の一部に含まれていなければならない。

事例

事例 1: HTML フォームの必須項目

オンラインフォームで「必須項目は赤で示され、(required) とマーク付けされている。」と指示されている。「(required)」という手がかりが label 要素の中に含まれる。

コード例:

<label for="lastname" class="required">Last name (required): </label>
<input id="lastname" type="text" size="25" value=""/>
<style type="text/css">
  .required {
    color:red;
  }
</style>

参考リソース

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

G14: 色の違いで伝えている情報をテキストでも入手可能にする

検証

手順

色の差で情報を表示しているコンテンツの場合:

同じ情報がテキスト又は文字による手がかりを通して利用可能であることを確認する。

期待される結果

1. の結果が真である。

G206: 利用者が横スクロールをしなくてもテキストの行を読めるようにするような、レイアウトを切り替えるオプションをコンテンツの中で提供する

適用 (対象)

スタイル切り替えをサポートしている全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.8 (視覚的提示)
- クイックリファレンス 1.4.8 (視覚的提示)
- 達成基準 1.4.8 (視覚的提示)を理解する

解説

制作者は、横スクロールを必要とするようなレイアウトを使用することがある。その場合でも、横スクロールを必要とせずに 1 行のテキストを読めるレイアウトに切り替えるオプションをコンテンツ内で提供することで、達成基準を満たすことができる。これは、標準的なスタイル切り替えの技術を用いることで達成できる。

コンテンツにアクセスするために横スクロールが必要であっても、1 行のテキストを読む際に横スクロールが必要ないようにコンテンツをレイアウトしている場合は、達成基準を満たすことに注意すること。

例えば、スプレッドシートで横スクロールを必要とするが、個々の列内で横スクロールが必要ないような場合は許容される (すなわち、他の列を見るためだけにスクロールが必要で、個々の列の左端や右端を表示するのにスクロールを必要としないような場合)。

注記: この達成方法は、適合していないなコンテンツに代わって適合している代替版のページを表示させるためのスタイル切り替え技術と組み合わせて使うこともできる。詳細は、C29: 適合している代替版を提供するために、スタイルスイッチャーを使用する及び適合している代替版を理解するを参照のこと。

事例

事例 1

不動産会社がオンラインのアニュアルレポートを印刷版と同じレイアウトで提供していて、1 行のテキストを読むために横スクロールを必要としている。スタイルシートを切り替えるコントロールがページにあり、横スクロールを必要としないレイアウトを提供している。

事例 2

金融のスプレッドシートがオンラインにある。1 月の住宅市場の動向がテキストで説明されている。右側の画面外に、9 月の住宅市場の動向を説明した列がある。利用者は 9 月エリアに右スクロールでき、ウィンドウ幅が最大の時に、更に横スクロールをしなくてもその列にある全てのテキストが読める。

C20: ブラウザがサイズ変更されるときに、行が平均で 80 字以下になるようなカラムの幅を設定するために、相対長さを使用する

検証

手順

フルスクリーンのウィンドウで横スクロールが必要なコンテンツを開く。
1 行のテキストを読むために横スクロールが不要になるように切り替えられるオプションがコンテンツに含まれていることを確認する。
そのオプションを有効にする。
すべての行のテキストを読むために横スクロールが必要ないことを確認する。

期待される結果

2. 及び 4. の結果が真である。

2. HTMLとXHTMLの達成方法

H2: 同じリソースに対して隣接する画像とテキストリンクを結合する

適用 (対象)

リンク機能を提供する HTML4、HTML5 及び XTHML ドキュメント

これは、次の達成基準に関連する達成方法である:

解説

訳注: WAIC では H2 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H2 も参照されたい。

この達成方法の目的は、テキストとアイコンの両方でリンクを提供する際、キーボード利用者や支援技術の利用者にとって混乱や困難を招くようなウェブページを作らないようにすることである。様々な利用者がテキストとアイコンを使いやすいと見出していることから、両方を提供することでリンクのアクセシビリティを向上させることができる。

よくあるリンクとして、テキストとアイコンの両方が互いに隣接しながらも、別々の要素としてレンダリングされているものがある。視覚的にはそれらは単一のリンクのように見えるが、それらを同様のリンクが隣接しているものとして受け取る利用者も多い。キーボード利用者の場合、冗長なリンクを通過していくのは面倒である。支援技術の利用者にとって、連続する同様のリンクに遭遇すると混乱する可能性がある。アイコンのテキストによる代替がリンクテキストの複製である場合、スクリーンリーダーは読み上げを 2 度繰り返すことになる。

制作者がリンク画像の代替テキストを省略した場合、テキストによる代替が視覚的なリンクと同じ目的を果たさないため、達成基準 1.1.1 を満たせなくなる。

この達成方法は、テキストと画像を一つの a 要素にまとめ、画像に空の代替テキストを指定してテキストの重複を排除することによって、混乱や困難がないリンクを提供するものである。このようにすることで、リンクにおける両方の表現が提供されつつも、キーボード利用者にとってリンクは一つだけとなり、ウェブページのリンク先リストを利用者に提供する補助技術も重複リンクを含まなくなる。

ページをレイアウトしやすくするために、テキストとアイコンのリンクを隣接したテーブルセルに分けることがある。WCAG 2.0 ではレイアウトテーブルの使用を禁止していないが、HTML の table 要素に定義されたセマンティックな意味を保持させ、コンテンツから提示を分離するコーティング手法に準拠するためにも、CSS ベースのレイアウトが推奨されている。CSS が使用されている場合には、この達成方法を適用して、テキストとアイコンのリンクを一つにまとめることができる。

事例

事例 1

アイコンとテキストが同じ a 要素の中にある。(HTML4 又は HTML5)

コード例:

 <a href="products.html">
   <img src="icon.gif" alt="">
   Products page
 </a>

事例 2

リンクにアイコンとテキストがあり、サイトのヘルプでそのアイコンの説明をしている。img には、サイトのヘルプで使われている名前であるテキストによる代替があり、ホームページのアイコンをクリックすることが説明されている。(HTML4 又は HTML5)

コード例:

<a href="home.html">
  <img src="house.gif" alt="home page icon">
  Go to the home page
</a>

訳注: WAIC では H2-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H2-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

参考リソース

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

HTML 4.01 - how to specify alt text

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。HTML 5.1§4.7.5.1. Requirements for providing text to act as an alternative for images を代わりに参照できる。

検証

手順

この達成方法を適用しているすべての a 要素に対して:

a 要素に含まれるすべての img 要素の alt 属性値が空に設定されていることを確認する。
a 要素に空の alt 属性値又はリンクテキストを補足し画像を説明する値のいずれかを持つ img 要素が含まれていることを確認する

期待される結果

上記の全ての結果が真である。

H4: リンク、フォームコントロール、及びオブジェクトを通して、論理的なタブ順序を作成する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.3 (フォーカス順序)
- クイックリファレンス 2.4.3 (フォーカス順序)
- 達成基準 2.4.3 (フォーカス順序)を理解する

解説

この達成方法の目的は、初期設定のタブ順番が十分でない時に、論理的なタブ順番を提供することである。多くの場合、「G59: コンテンツ内の順番及び関係に従った順序で、インタラクティブな要素を配置する」を用いることで十分であり、この達成方法は必要ではない。表示とは異なるタブ順番を設定すると、ユーザビリティ上の不具合を生じさせる可能性が高くなる。

場合によって、コンテンツ制作者はコード内のインタラクティブな要素の順番に従うことなく、コンテンツの関係をたどるタブ順番を指定しようとするかもしれない。この場合、インタラクティブな要素の tabindex 属性を使用することで選択肢の順番を指定できる。tabindex 属性には、0 から 32767 の間の値を付与する。

インタラクティブな要素が Tab キーを使ってナビゲートされる時、要素は tabindex 属性の値の増える順にフォーカスが与えられる。0 よりも大きな tabindex 値を持つ要素は、tabindex がない又は 0 の tabindex の要素の前にフォーカスを受けることになる。0 よりも大きな tabindex を持つ全ての要素がフォーカスを受け取った後、残りのインタラクティブな要素はウェブページに現れる順番でフォーカスが与えられる。

訳注: WAIC では H4 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H4 も参照されたい。

事例

事例 1

系図の検索フォームで結婚記録を検索する。検索フォームには花嫁及び花婿用のいくつかの入力フィールドがある。フォームは、データテーブルを用いてマークアップされ、1 列目に花婿、2 列目に花嫁のフィールドがある。コンテンツの順番は行ごとであるが、コンテンツ制作者はフォームを列ごとにナビゲートする方がより論理的であると感じている。この方法では、全ての花婿の条件は花嫁の条件へ移る前に記入できる。入力フィールドの tabindex 属性は、列ごとにナビゲートするタブ順番を指定するのに使用される。

コード例:

<form action="#" method="post">
 <table summary="the first column contains the search criteria 
  of the groom, the second column the search criteria of 
  of the bride">
 <caption>Search for marriage records</caption>
 <tr>
   <th>Search criteria</th>
   <th>Groom</th>
   <th>Bride</th>
 </tr>
 <tr>
  <th>First name</th>
  <td><input type="text" size="30" value="" name="groomfirst" 
      title="First name of the groom" tabindex="1"></td>
  <td><input type="text" size="30" value="" name="bridefirst" 
       title="First name of the bride" tabindex="4"></td>
 </tr>
 <tr>
  <th>Last name</th>
  <td><input type="text" size="30" value="" name="groomlast" 
      title="Last name of the groom" tabindex="2"></td>
  <td><input type="text" size="30" value="" name="bridelast" 
      title="Last name of the bride" tabindex="5"></td>
 </tr>
 <tr>
  <th>Place of birth</th>
  <td><input type="text" size="30" value="" name="groombirth" 
      title="Place of birth of the groom" tabindex="3"></td>
  <td><input type="text" size="30" value="" name="bridebirth" 
      title="Place of birth of the bride" tabindex="6"></td>
 </tr>
</table>
</form>

訳注: WAIC では H4-1 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H4-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2

ウェブページは上部の右端に検索フィールドを提供している。コンテンツの順番が最初ではないが、タブ順番が最初になるようにフィールドには tabindex="1" が与えられている。

訳注: WAIC では H4-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H4-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 3

tabindex 値は、連続した番号である必要はなく、特定の値で始まる必要もない。値は一意的である必要もない。同じ tabindex 値を持つ要素は、その文字の出現順にナビゲートされる。

タブ順番がコンテンツ順番に従っているコンテンツのセクションにおいて、個々の要素に異なる tabindex 値を指定するよりも、全ての要素に同じ値を与えることでエラーを起こりにくくすることが可能である。それらの要素を再配列する、又は新しい要素を加える、及び論理的なタブ順番を設定することは容易である。

コード例:

 <a href="xxx" tabindex = "1">First link in list</a>
<a href="xxx" tabindex = "1">Second link in list</a>
<a href="xxx" tabindex = "1">Link that was added long 
  after the original list was created</a>
<a href="xxx" tabindex = "1">Third link in list</a>
  ...
<a href="xxx" tabindex = "1">Twentieth link in list</a>

参考リソース

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

Tabbing navigation in the HTML 4.01 specification

検証

手順

tabindex が使われているかどうかを確認する。
tabindex が使われている場合、tabindex 属性により指定されたタブ順番がコンテンツの関係に従っていることを確認する。

期待される結果

2. の結果が真である。

H24: イメージマップの `area` 要素にテキストによる代替を提供する

適用 (対象)

area 要素を含む HTML 及び XHTML ドキュメント

これは、次の達成基準に関連する達成方法である:

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

H24 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、イメージマップ上の選択可能領域と同じ役割を果たすテキストによる代替を提供することである。イメージマップは、area 要素によって定義された選択可能領域によって分割されている 1 枚の画像である。各領域は、他のウェブページや、現在のウェブページ内の他の場所へのリンクである。各 area 要素の alt 属性は、その画像の選択可能領域と同じ目的を果たすものである。

訳注: WAIC では H24 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H24 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

訳注: WAIC では H24 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H24 も参照されたい。

事例

事例 1

この事例では、イメージマップ上の各領域の目的を示したテキストを提供するのに、area 要素の alt 属性を利用している。

コード例:

<img src="welcome.gif" usemap="#map1" 
    alt="Areas in the library. Select an area for
more information on that area." /> 
<map id="map1" name="map1">
  <area shape="rect" coords="0,0,30,30"
    href="reference.html" alt="Reference" />
  <area shape="rect" coords="34,34,100,100"
    href="media.html" alt="Audio visual lab" />
</map>

参考リソース

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

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記はそれぞれ、HTML 5.1§4.7.17. Image maps 及び HTML 5.1§4.7.5.1. Requirements for providing text to act as an alternative for images を代わりに参照できる。

検証

手順

イメージマップ上の各 area 要素について:

その area 要素に alt 属性があることを確認する。
alt 属性で指定したテキストによる代替が、イメージマップの area 要素で参照されるイメージマップ画像の一部と同じ目的を果たしていることを確認する。

期待される結果

上記全ての結果が真である。

H25: title 要素を用いて、ページタイトルを提供する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.2 (ページタイトル)
- クイックリファレンス 2.4.2 (ページタイトル)
- 達成基準 2.4.2 (ページタイトル)を理解する
注記: この達成方法は、達成基準 2.4.2 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 2.4.2 を理解するを参照すること。

解説

この達成方法の目的は、フレームセットの個々のフレームに含まれるものを含む全ての HTML 及び XHTML ドキュメントにおいて、head 要素のセクション内で title 要素を用いてドキュメントの目的を簡単な文言で定義することである。これにより、ページの本文でオリエンテーション情報を探すことなく、利用者はサイト内の自分のいる場所を素早く見つけることができる。

ドキュメント内で一度しか現れない (必須の) title 要素は、ほとんど全ての HTML 及び XHTML の要素で利用されるかもしれない title 属性と異なることに注意する。

訳注: WAIC では H25 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H25 も参照されたい。

事例

事例 1

この事例はドキュメントのタイトルを定義している。

コード例:

<html xmlns="http://www.w3.org/1999/xhtml">   
   <head>     
      <title>The World Wide Web Consortium</title>     
   </head>   
   <body>     
      ...   
   </body> 
</html>

参考リソース

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

HTML 4.01 TITLE element

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記は、HTML 5.2§4.2.2. The title element を代わりに参照できる。

検証

手順

HTML 又は XHTML ドキュメントのソースコードを調べ、head 要素内に空でない title 要素があることを確認する。
title 要素がドキュメントを説明していることを確認する。

期待される結果

1. 及び 2. の結果が真である。

H28: abbr 要素を用いて、略語の定義を提供する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.4 (略語)
- クイックリファレンス 3.1.4 (略語)
- 達成基準 3.1.4 (略語)を理解する

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

H28 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、abbr 要素を用いることで、略語に対して元の語又は定義を提供することである

abbr 要素は、頭字語や頭文字語を含むあらゆる略語に用いてよい。HTML4 及び XHTML では、頭文字語や頭字語は acronym 要素を用いてマークアップすることもできる。abbr 要素は、頭字語や頭文字語を含むあらゆる略語に用いてよい。HTML5 以降では、より一般的な abbr 要素の利用が提案され、acronym 要素は廃止されている。

訳注: HTML 4、XHTML (XHTML 1.0 及び XHTML 1.1) は Superseded Recommendation としてマークされ、廃止された仕様である。

事例

事例 1: abbr 要素を用いて略語の元の語を示す

コード例:

<p>Sugar is commonly sold in 5 <abbr title="pound">lb.</abbr> bags.</p>
<p>Welcome to the <abbr title="World Wide Web">WWW</abbr>!</p>

事例 2: abbr 要素を用いて略語の定義を示す

コード例:

<p>Tasini <abbr title="and others">et al.</abbr> <abbr title="versus">v.</abbr>
The New York Times <abbr title="and others">et al.</abbr> is the landmark lawsuit 
brought by members of the National Writers Union against ......</p>

事例 3: abbr 要素を用いて頭字語の元の語を示す

コード例:

 <p>The use of <abbr title="Keep It Simple Stupid">KISS</abbr> became popular in ...</p>

事例 4: abbr 要素を用いて頭文字語の元の語を示す

コード例:

 <p><abbr title="World Wide Web">WWW</abbr></p>

参考リソース

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

G102: 略語の元の語又は説明を提供する

検証

手順

略語それぞれに、abbr 要素で元の語や定義を指定していることを確認する。

期待される結果

1.の結果が真である。

H30: a 要素のリンクの目的を説明するリンクテキストを提供する

適用 (対象)

リンク (<a href> 要素) を含む HTML 及び XHTML ドキュメント

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、リンク先を説明するテキストを a 要素のコンテンツとして提供することにより、リンクの目的を説明することである。その説明により、利用者はこのリンクとウェブページ内にある他のリンクとの違いが区別でき、利用者がリンクをたどるかどうかを決定するのを助ける。一般的に、遷移先の URI では、そのリンクの目的を説明したことにはならない。

画像がリンクの唯一のコンテンツであるとき、画像のテキストによる代替がそのリンクに固有の機能を説明している。

リンクのコンテンツがテキスト及び一つ以上の画像を含むとき、テキストがリンクの目的を十分に説明している場合、画像は空のテキストによる代替であってもよい。(H67: 支援技術が無視すべき画像に対して、img 要素の alt テキストを空にして、title 属性を付与しない (HTML) を参照。) 画像がリンクの目的以外にも情報を伝えるときには、画像に適切な代替テキストも付与しなければならない。

訳注: WAIC では H30 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H30 も参照されたい。

事例

事例 1

HTML において、a 要素のテキストコンテンツを用いてリンクの目的を説明する。

コード例:

<a href="routes.html">
  Current routes at Boulders Climbing Gym
</a>

事例 2

画像のリンクの目的を説明するために、img 要素に alt 属性を使用する。

コード例:

<a href="routes.html">
   <img src="topo.gif" alt="Current routes at Boulders Climbing Gym" /> 
</a>

訳注: WAIC では H30-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H30-2 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 3

アンカー (a) 要素が img 要素に加えてリンクの目的を説明するテキストを含むときは、空の alt 属性を使用する。リンクテキストはページ上で画像の隣りに表示されることに注意する。

コード例:

<a href="routes.html">
  <img src="topo.gif" alt="" />
  Current routes at Boulders Climbing Gym
</a>

事例 4

サイトでは、製品の詳細ページの「Feedback」リンクをクリックすることで、利用者がログインしたときに製品に関するフィードバックを提供することができる。他の利用者又は製品メーカーは、フィードバックに応答することができる。フィードバックのリンクは、利用者のフィードバックへの応答が利用可能な場合に、「Feedback」テキストの前にアイコンを表示する。ヘルプ情報は、このアイコンを二重引用符を含む吹き出しとして説明し、アイコン自体を例として示している。ヘルプテキストにおけるアイコンのテキストによる代替は、「応答受信アイコン」である。複数のモダリティを使用してこのアイコンを識別できるように、製品の詳細ページ (応答が利用可能な場合) で同じテキストによる代替が使用される。

コード例:

<a href="prod_123_feedback.htm">Feedback 
         <img src="response.gif" width="15" height="15" alt="Response received icon" /></a>

事例 5

リンクはテキスト及びアイコンを含み、アイコンはリンク先についての追加情報を提供している。

コード例:

<a href="WMFP.pdf">
Woodend Music Festival Program
<img src="pdficon.gif" alt="PDF format"/>
</a>

訳注: WAIC では H30-5 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H30-5 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 6

MyCorp 社の年次レポートは企業のウェブサイト上から PDF ファイルとして入手でき、年次企業予算は Excel ファイルとして入手できる。

注記: 多くの利用者は、ファイルを開く際に新しいアプリケーションが開く場合は、あらかじめファイルの種類を知りたいので、このような追加情報を含めるのはしばしば便利であると考えられる。ただし、この達成基準を満たすには必須ではない。

コード例:

<p>
<a href=”2009mycorp_report.pdf”>MyCorp 2009 Annual Report (pdf)</a><br />
<a href=”2009mycorp_budget.xls”>MyCorp 2009 Annual Budget (Excel)</a>
</p>

事例 7

HTML5 においてブロックレベル要素をリンクで囲む。

コード例:

<article>
<a href="news.html">
<h3>Budget Debate Continues in Parliament</h3>
<p class="subhead"><img class="alertimg" src="alerticon.png" alt="Breaking News" height="30" width="30">Members of Parliament continued vigorous debate on three challenging issues surrounding the upcoming year's budget.</p>
<p>Read more</p>
</a>
</article>

ブロックレベル要素をリンクで囲む実例を示す。

訳注: HTML5 ではブロックレベル要素は定義されていない。ブロックレベル要素 - HTML: HyperText Markup Language | MDN も参照のこと。

参考リソース

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

HTML 4.01 - how to specify alt text

検証

手順

この達成方法を使用したコンテンツのそれぞれのリンクに対して:

テキスト又は非テキストコンテンツのテキストによる代替が a 要素に含まれている。
img 要素だけが a 要素のコンテンツである場合、img 要素のテキストによる代替がリンクの目的を説明している。
a 要素が一つ以上の img 要素を含み、かつ img 要素のテキストによる代替が空の場合、リンクのテキストがリンクの目的を説明していることを確認する。
a 要素がテキストのみを含んでいる場合、そのテキストがリンクの目的を説明していることを確認する。

期待される結果

上記の全ての結果が真である。

H32: 送信ボタンを提供する

適用 (対象)

フォームのコントロールを含むコンテンツ

これは、次の達成基準に関連する達成方法である:

達成基準 3.2.2 (入力時)
- クイックリファレンス 3.2.2 (入力時)
- 達成基準 3.2.2 (入力時)を理解する

解説

この達成方法の目的は、利用者がコンテキストの変化を明示的に要求できるメカニズムを提供することである。送信ボタンの使用目的は、フォームに入力されたデータを送信する HTTP リクエストを生成することであるため、コンテキストの変化を起こすために使うものとして適切なコントロールである。

訳注: WAIC では H32 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H32 も参照されたい。

事例

事例 1

これは送信ボタンを持つフォームの基本的な事例である。

コード例:


<form action="http://www.example.com/cgi/subscribe/" method="post"><br /> 
 <p>Enter your e-mail address to subscribe to our mailing list.</p><br /> 
 <label for="address">Enter email address:</label><input type="text" 
 id="address" name="address" /> 
 <input type="submit" value="Subscribe" /><br /> 
</form>

事例 2

次の事例では、利用者が要求したページを転送する (action 属性により指定された) サーバーサイドスクリプトを使用している。

コード例:

 <form action="http://www.example.com/cgi/redirect/" method="get"><br /> 
    <p>Navigate the site.</p><br /> 
    <select name="dest"><br /> 
      <option value="/index.html">Home</option/><br /> 
      <option value="/blog/index.html">My blog</option/><br /> 
      <option value="/tutorials/index.html">Tutorials</option/><br /> 
      <option value="/search.html">Search</option/><br /> 
    </select><br /> 
  <input type="submit" value="Go to Page" /><br /> 
  </form>

参考リソース

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

Navigational pulldown menus in HTML by Jukka Korpela discusses a few techniques that work or do not work.

検証

手順

コンテンツ内の全てのフォームを見つける。
それぞれのフォームに、送信ボタン (input type="submit"、input type="image" 又は button type="submit") があることを確認する。

期待される結果

2. の結果が真である。

H33: title 属性を用いて、リンクテキストを補足する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

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

H33 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、リンクを説明する追加情報を提供するための、a 要素の title 属性の利用方法を示すことである。title 属性は、リンクの目的を明らかにしたり、詳しく説明したりするのに役立つ追加情報の指定に用いる。もし title 属性を通して提供する補足情報が、警告文のように利用者がリンクをたどる前に知っておくべき内容であれば、title 属性ではなくリンクテキストとして提供すべきである。

title 属性へのアクセス方法について、ユーザエージェントごとにサポートが大きく異なるため、コンテンツ制作者はこの達成方法を用いるときは注意を払うべきである。この理由から、コンテンツ制作者は達成方法 C7: リンクテキストの一部を非表示にするために、CSS を使用する (CSS) 又は H30: a 要素のリンクの目的を説明するリンクテキストを提供する (HTML) を利用することが望ましい。

訳注: HTML 5.2§3.2.5.1. The title attribute の Warning で述べられているように、多くのユーザエージェントではアクセシブルな形でこの属性を公開しないので、title 属性に依存することを勧めていない。

訳注: WAIC では H33 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H33 も参照されたい。

事例

事例 1: リンクの目的を明らかにする

コード例:

<a href="http://example.com/WORLD/africa/kenya.elephants.ap/index.html" 
   title="Read more about failed elephant evacuation">
   Evacuation Crumbles Under Jumbo load
</a>

参考リソース

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

Displaying tooltips when elements receive focus

検証

手順

a 要素のソースコードについて、次のことを調べる。

title 属性のある a 要素では、リンクテキストの文言とともに title 属性がそのリンクの目的を示していることを確認する。

期待される結果

1.の結果が真である。

H34: インラインでテキストの方向を混在させるために、Unicode の right-to-left mark (RLM) 又は left-to-right mark (LRM) を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.2 (意味のある順序)
- クイックリファレンス 1.3.2 (意味のある順序)
- 達成基準 1.3.2 (意味のある順序)を理解する
注記: この達成方法は、達成基準 1.3.2 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.3.2 を理解するを参照すること。

解説

この達成方法の目的は、HTML の双方向性アルゴリズムが望ましくない結果を生じるとき時に、それを無効にするために Unicode 制御文字の right-to-left mark と left-to-right mark を用いることである。たとえば、スペース又は句読点のようなニュートラルな文字が異なる方向性のテキストの間に置かれている時に必要となることがある。この達成方法で用いられているコンセプトは、W3C 文書の「What you need to know about the bidi algorithm and inline markup」に書かれている。

訳注: 上記の「What you need to know about the bidi algorithm and inline markup」は、「Inline markup and bidirectional text in HTML」とタイトルが変更されている。また、Unicode controls vs. markup for bidi support によれば、Unicode の right-to-left mark (RLM) 又は left-to-right mark (LRM) よりも、dir 属性による書字方向の制御が勧められている。H56: 入れ子になったテキストの表記方向に伴う問題を解決するために、インライン要素の dir 属性を使用する (HTML) も参照のこと。

Unicode 制御文字の right-to-left mark 及び left-to-right mark は、以下に示すように、そのまま、又は文字符号か数字符号の参照によって挿入することが可能である。

left-to-right mark (LRM): &lrm; 又は ‎ (U+200E)
right-to-left mark (RLM): &rlm; 又は ‏ (U+200F)

双方向性のアルゴリズムが原因で、ソースコード編集者は期待通りに文字符号や数字符号の参照を表示できないことがある。

事例

事例 1

この事例では、英語の文章の間にあるアラビア語のフレーズを示している。感嘆符はアラビア語のフレーズの一部であり、その左側にあるべきである。それはアラビア文字とラテン文字の間であり、段落全体の方向が LTR (左から右) であるため、双方向性のアルゴリズムはアラビア語のフレーズの右側に感嘆符を置いている。

The title is "مفتاح معايير الويب!" in Arabic.

視覚的に並び替えられた ASCII バージョン (右から左へのテキストは大文字、左から右は小文字):

the title is "HCTIWS SDRADNATS BEW!" in arabic.

表示されたテキスト (以下を参照) を見るとき、感嘆符の直後に Unicode の right-to-left mark を挿入することによって、感嘆符を正しい位置に置くことになる。right-to-left mark を挿入するために、エスケープ文字又は (不可視の) 制御文字を使用することができる。

The title is "مفتاح معايير الويب!‏" in Arabic.

視覚的に並び替えられた ASCII バージョン:

the title is "!HCTIWS SDRADNATS BEW" in arabic.

参考リソース

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

H56: 入れ子になったテキストの表記方向に伴う問題を解決するために、インライン要素の dir 属性を使用する

検証

手順

テキストの方向が変わっている箇所のソースを調べる。
テキストの方向が変わる時、スペース又は句読点のようなニュートラルな文字が初期設定ではない方向でレンダリングされたテキストに隣接しているかどうかを確認する。
上記 2. が真であり、かつ HTML の双方向性のアルゴリズムがニュートラルな文字の誤った配列を生み出している場合、ニュートラルな文字の後に Unicode の right-to-left 又は left-to-right mark があり、ニュートラルな文字を前の文字列の一部として配置させているかどうかを確認する。

期待される結果

3. の結果が真である。

H35: `applet` 要素にテキストによる代替を提供する

適用 (対象)

applet 要素が非推奨ではない場合に、Java アプレットを読み込んでいる HTML 及び XHTML ドキュメント

訳注: applet 要素は、仕様では廃止された要素であり、さらに多くのモダンブラウザでは廃止された機能でもある。詳細については、MDN の applet 要素を参照されたい。また、Oracle 社の Oracle Java SE サポート・ロードマップによれば、Java Plugin のサポートは 2019 年 3 月までと告知されていることに注意されたい。

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

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

H35 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、アプレットのラベルを提供する alt 属性を用いること及び applet 要素のボディにテキストによる代替を提供することによって、アプレットに対するテキストによる代替を提供することである。この達成方法では、ユーザエージェントごとに、alt 属性及び applet 要素のボディのサポート状況が異なるため、両方のメカニズムを必要としている。

訳注: WAIC では H35 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H35 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例

事例 1: 三目並べゲームのアプレット

コード例:

<applet code="tictactoe.class" width="250" height="250" alt="tic-tac-toe game">
   tic-tac-toe game
</applet>

G94: 非テキストコンテンツに対して、それと同じ目的を果たし、かつ同じ情報を示す、簡潔なテキストによる代替を提供する

検証

手順

applet 要素のソースコードを見る
アプレットに対するテキストによる代替が applet 要素の alt 属性にあることを確認する
アプレットに対するテキストによる代替が applet 要素のボディの中にあることを確認する。

期待される結果

2. 及び 3. の結果が真である。

H36: 送信ボタンとして用いる画像の alt 属性を使用する

適用 (対象)

画像の送信/実行ボタンを使用するコンテンツに適用する。

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

解説

この達成方法の目的は、type 属性が「image」である input 要素において、input 要素の alt 属性を機能的なラベルを提供するのに使用することである。このラベルは、画像の説明をするのではなく、ボタンの機能を説明する。もしそのページに、それぞれ異なる結果につながる複数の送信/実行ボタンがあるならば、ラベルは特に重要である。

input 要素は、多くの種類のフォームのコントロールを作成するのに使用される。HTML 及び XHTML の DTD では、これら全てで alt 属性を用いることができるが、本来は画像の送信/実行ボタンだけに使用すべきである。ユーザエージェントでは、他の種類のフォームのコントロールでの alt 属性の使用をサポートしていないため、これらのコントロールをラベル付けするために他のメカニズムを用いている。

訳注: WAIC では H36 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H36 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

訳注: WAIC では H36 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H36 も参照されたい。

事例

事例 1

alt 属性がある input 要素

コード例:

<form action="http://example.com/prog/text-read" method="post">
  <input type="image" name="submit" src="button.gif" alt="Submit" />
</form>

参考リソース

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

G94: 非テキストコンテンツに対して、それと同じ目的を果たし、かつ同じ情報を示す、簡潔なテキストによる代替を提供する

検証

手順

type 属性の値が "image" であるすべての input 要素に、alt 属性があることを確認する。
その alt 属性がボタンの機能を説明していることを確認する。

期待される結果

1. 及び 2. の結果が真である。

H37: `img` 要素の `alt` 属性を使用する

適用 (対象)

HTML ドキュメントで用いられている画像

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

解説

img 要素を使用するときは、簡潔なテキストによる代替を alt 属性に指定する。注記: この属性の値は「ALT テキスト」ともいう。

画像がコンテンツを理解するために重要な文字を含むとき、代替テキストにはそれらの文字を含めなくてはならない。これにより、代替テキストはページ上で画像と同じ役割を果たすことができる。代替テキストは、画像自体の視覚的な特徴を説明する必要はないが、画像と同じ意味を伝えなければらないことに注意する。

訳注: WAIC では H37 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H37 も参照されたい。

事例

事例 1

ウェブサイト上にある画像は、無料のニュースレターへのリンクである。画像はテキスト「Free newsletter. Get free recipes, news, and more. Learn more.」を含んでいる。画像の代替テキストは、画像にあるテキストと一致している。

コード例:

<img src="newsletter.gif" alt="Free newsletter. 
   Get free recipes, news, and more. Learn more." />

訳注: WAIC では H37-1 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H37-1 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 2

ウェブサイト上にある画像は、ビルの間取り図を表現している。その画像は、各部屋の部分がインタラクティブに操作できるイメージマップである。代替テキストは「ビルの間取り図。各部屋の目的又は内容に関する詳しい情報は、部屋を選択してください」である。「部屋を選択してください」という指示により、画像がインタラクティブであることを示している。

訳注: WAIC では H37-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H37-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

参考リソース

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

HTML 4.01 IMG element

HTML 4.01 alt attribute

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記はそれぞれ、HTML 5.1§4.7.5. The img element 及び HTML 5.1§4.7.5.1. Requirements for providing text to act as an alternative for images を代わりに参照できる。

検証

手順

コンテンツに含まれる img 要素それぞれを調べる。
意味を伝える img 要素それぞれが、alt 属性を含んでいることを確認する。
画像にコンテンツを理解するために重要な単語が含まれている場合、その単語がテキストによる代替に記述されていることを確認する。

期待される結果

2. 及び 3. の結果が真である。

H39: データテーブルのキャプションとデータテーブルを関連付けるために、caption 要素を使用する

適用 (対象)

HTML 及び XHTML のデータテーブル

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

解説

この達成方法の目的は、提示でテーブルの表題を付ける場合に、プログラムで解釈できるようにデータテーブルと表題を関連付けることである。表題はテーブルの識別子であり、タイトル又は見出しのような働きをする。

caption 要素は表題のテキストのための適切なマークアップであり、(初期状態では) 表示上も、テーブルの識別子がそのテーブルに関連付けられていることを保証するものである。さらに、caption 要素を用いることによって、音声読み上げソフトウェアがテーブルの表題に利用者を直接誘導することも可能になる。

caption 要素は、テーブルに summary 属性を指定しているかどうかに関わらず利用できる。caption 要素はテーブルを特定するもの、summary 属性はテーブルの概要を提供したり、見方を説明したりするものである。両方とも指定する場合、summary 属性に caption 要素と同じ情報を含めるべきではない。

注記: WCAG 2.0 はレイアウトテーブルの利用を禁止していないが、CSS ベースのレイアウトを推奨している。HTML 及び XHTML の table 要素に与えられたセマンティックな意義を守り、コンテンツから提示を分離するというコーディングの実践に沿うためである。テーブルをレイアウトのために利用する場合、caption 要素は使用しない。レイアウトテーブルの目的は、コンテンツの配置を制御することのみであって、テーブルそのものは利用者から見て「透明」であるべきである。caption 要素を用いることによってテーブルの存在を示してしまうと、この透明性を壊すことになる。F46: 達成基準 1.3.1 の失敗例－レイアウトテーブルで、th 要素、caption 要素、又は空ではない summary 属性を使用しているを参照のこと。

訳注: WAIC では H39 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H39 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

訳注: WAIC では H39 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H39 も参照されたい。

事例

事例 1: スケジュールカレンダーの表題

コード例:

<table>
<caption>Schedule for the week of March 6</caption>
...</table>

参考リソース

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

HTML 4.01 Table Captions: The CAPTION element

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記は、HTML 5.2§4.9.2. The caption elementを代わりに参照できる。

検証

手順

各データテーブルごとに:

テーブルに caption 要素が含まれていることを確認する。
caption 要素の内容がテーブルを識別していることを確認する。

期待される結果

1. 及び 2. の結果が真である。

H40: 記述リストを使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.3 (一般的ではない用語)
- クイックリファレンス 3.1.3 (一般的ではない用語)
- 達成基準 3.1.3 (一般的ではない用語)を理解する

解説

この達成方法の目的は、名前または用語の説明を記述リストの形式で提供することである。リストは dl 要素を用いてマークアップし、その中では用語それぞれを個別の dt 要素に含め、直後の dd 要素に説明を含める。意味のある順序が確保されていれば、複数の用語を単一の説明に、単一の用語を複数の説明に関連付けることもできる。title 属性を用いて、記述リストに関する補足情報を提供することもできる。記述リストを使用することで、提示が変化しても、用語とその説明が一つの単位としてグループ化され、意味的な関連が保証される。

説明がアルファベット順に並べられている場合は、記述リストを使用するのが最も容易である。記述リストの一般的な使用法は用語集である。

注記: HTML5 では、「記述リスト」という名前が導入された。以前のバージョンでは、これらのリストは「定義リスト」と呼ばれていた。

事例

事例 1

海事用語の記述リストを、航海に関するウェブサイトで利用している。

コード例:

<dl title="Nautical terms">
  <dt>Knot</dt>
  <dd>
    <p>A <em>knot</em> is a unit of speed equaling 1 
      nautical mile per hour (1.15 miles per hour or 1.852 
      kilometers per hour).</p>
  </dd>
  <dt>Port</dt>
  <dd>
    <p><em>Port</em> is the nautical term (used on 
      boats and ships) that refers to the left side
      of a ship, as perceived by a person facing towards 
      the bow (the front of the vessel).</p>
  </dd>
  <dt>Starboard</dt>
  <dd>
    <p><em>Starboard</em> is the nautical term (used 
      on boats and ships) that refers to the right 
      side of a vessel, as perceived by a person 
      facing towards the bow (the front of the vessel).</p>
  </dd>
</dl>

参考リソース

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

G62: 用語集を提供する

検証

手順

用語とそれに関する説明の組み合わせについて:

そのリストが、dl 要素に含まれていることを確認する。
リストの各用語が dt 要素内に含まれていることを確認する。
同じ説明を共有する複数の用語があるときに互いの dt 要素が連続することを確認する。
各用語に対する説明が一つ以上の dd 要素に含まれていることを確認する。
用語を含む一つ以上の dt 要素の直後に、一つ以上の dd 要素があることを確認する。

期待される結果

上記の全ての結果が真である。

H42: 見出しを特定するために、h1 要素～ h6 要素を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

解説

この手法の目的は、HTML 及び XHTML の見出しマークアップを用いて、コンテンツの見出しにセマンティックなコードを提供することである。見出しマークアップは、支援技術がテキストの見出し状態を利用者に提示することを可能にする。スクリーンリーダーは、コードを認識し、そのレベル、ビープ音、又は他の聴覚インジケーターを備えた見出しとしてテキストをアナウンスすることができる。スクリーンリーダーはまた、見出しマークアップをナビゲートすることもできる。これは、スクリーンリーダー利用者が関心のあるコンテンツをより迅速に見つけるための効果的な方法である。オーサリングされた視覚表示を変更する支援技術はまた、見出しマークアップで識別できる見出しのための適切な代替視覚表示を提供することもできる。

訳注: WAIC では H42 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H42 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例

事例 1: 階層的な見出し構造

以下の事例では、h3 が h2 のサブセクションで、h2 が h1 のサブセクションとなっていて、見出しが階層的なレイアウトに用いられている。

コード例:

<h1>Plant Foods that Humans Eat</h1>
<p>There are an abundant number of plants that humans eat...</p>
<h2>Fruit</h2>
<p> A fruit is a structure of a plant that contains its
  seeds...</p>
<h3>Apple</h3>
<p>The apple is the pomaceous fruit of the apple tree...</p>
<h3>Orange</h3>
<p>The orange is a hybrid of ancient cultivated origin...</p>
<h3>Banana</h3>
<p>Banana is the common name for herbaceous plants ...</p>
<h2>Vegetables</h2>
<p>A vegetable is an edible plant or part of a plant other than a
  sweet fruit ...</p>
<h3>Broccoli</h3>
<p>Broccoli is a plant of the mustard/cabbage family ... </p>
<h3>Brussels sprouts</h3>
<p>The Brussels sprout of the Brassicaceae family, is a Cultivar
  group of wild cabbage ...</p>
<h3>Green beans</h3>
<p>Green beans have been bred for the fleshiness, flavor, or
  sweetness of their pods...</p>

事例 2: 3段組レイアウトの見出し設定

この事例では、3 段組の真ん中にページのメインコンテンツがある。メインコンテンツは、ページ内で最初のコンテンツではないが、そのタイトルはページタイトルと同じで、h1 要素でマークアップされている。1 列目と 3 列目のコンテンツはそれほど重要ではなく、h2 でマークアップされている。

注記: 以下のコード例は、ウェブページの特定のセクションに対して用いるべき見出しレベルを規定するものではないことに留意することが重要である。レイアウトする際には、各カラムの最初に見出しを同じ見出しレベル (例えば、h1) で提示したり、またはコード例にあるようにメインコンテンツに関してその重要度を反映した見出しレベルで提示したりすることが可能である。

訳注: WAIC では H42 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H42 も参照されたい。

コード例:

<head>
 <title>Stock Market Up Today</title>
 </head>
 <body>
 <!-- left nav -->
 <div class="left-nav">
 <h2>Site Navigation</h2>
 <!-- content here -->
 </div>
 <!-- main contents -->
 <div class="main">
 <h1>Stock Market up today</h1>
 <!-- article text here -->
 </div>
 <!-- right panel -->
 <div class="left-nav">
 <h2>Related links</h2>
 <!-- content here -->
 </div>
 </body>

参考リソース

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

検証

手順

コンテンツが見出しであるときに、見出しマークアップを利用している。
コンテンツが見出しでないときは、見出しマークアップを利用していない。

期待される結果

1. 及び 2. の結果が真である。

H43: データテーブルのデータセルを見出しセルと関連付けるために、id 属性及び headers 属性を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

解説

この達成方法の目的は、(データテーブル内の) 各データセルを適切な見出しセルと関連付けることである。まず、各データセル (td 要素) に headers 属性を付加する。次に、データセルの見出しとなるセルには id 属性を指定する。データセルの headers 属性で指定するのは、関連付けられる見出しセルの id 属性値であり、二つ以上の id を含める場合はスペース区切りで列挙する。

この達成方法は、データセルを二つ以上の行見出し及び／又は列見出しに関連付ける場合に利用する。こうすることで、th 要素のみ、または th 要素に scope 属性を付けただけでは、データセルと見出しセルの関係が複雑すぎて定義できない場合でも、スクリーンリーダーは各データセルと関連付けられている見出しセルを読み上げることができる。また、提示形式が変わったとしても、これらの複雑な関係を知覚しやすくなる。

この達成方法を、レイアウトテーブルに利用することは推奨しない。なぜなら、レイアウトのためにテーブルを利用する際には、意味がないにも関らず何らかの関係性を示してしまうことになるからである。

訳注: WAIC では H43 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H43 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

訳注: WAIC では H43 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H43 も参照されたい。

事例

事例 1: 行見出しが複数あるテーブル

コード例:

<table>
   <tr>
     <th rowspan="2" id="h">Homework</th>
     <th colspan="3" id="e">Exams</th>
     <th colspan="3" id="p">Projects</th>
   </tr>
   <tr>
     <th id="e1" headers="e">1</th>
     <th id="e2" headers="e">2</th>
     <th id="ef" headers="e">Final</th>
     <th id="p1" headers="p">1</th>
     <th id="p2" headers="p">2</th>
     <th id="pf" headers="p">Final</th>
   </tr>
   <tr>
    <td headers="h">15%</td>
    <td headers="e e1">15%</td>
    <td headers="e e2">15%</td>
    <td headers="e ef">20%</td>
    <td headers="p p1">10%</td>
    <td headers="p p2">10%</td>
    <td headers="p pf">15%</td>
   </tr>
  </table>

参考リソース

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

HTML 4.01 header information with data cells

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記は、HTML 5.2§4.9.10. The th element を代わりに参照できる。

検証

手順

レイアウトテーブルを確認する: 内容が同じ行と列の両方に含まれる他のセルの内容と関係があるかどうか判断する。「いいえ」の場合、そのテーブルはレイアウトテーブルである。「はい」の場合、そのテーブルはデータテーブルである。
データテーブルに対しては、二つ以上の行見出し及び／又は列見出しと関連付けられているあらゆるセルが、そのセルに関連付けられている全ての見出しの id を指定している headers 属性を含むことを確認する。
あらゆるセルに id 属性又は headers 属性が含まれるデータテーブルの場合:
1. データセルの headers 属性で指定した各 id が、見出し要素の id 属性値と一致していることを確認する。
2. データセルの headers 属性が、そのデータセルと関連付けられた全ての見出しの id 属性値を含んでいることを確認する。
3. 全ての id が一意であることを確認する (つまり、ページの中で二つ以上の要素が同じ id を持つことはできない)。

期待される結果

テーブルがレイアウトテーブルの場合、どのセルにも headers 属性又は id 属性がない。
テーブルがデータテーブルで、かつセルが id 属性を含む場合、3.a、3.b、及び 3.c の結果が真である。
テーブルがデータテーブルで、かつ二つ以上の行見出し及び／又は列見出しと関連付けられた全てのセルについて、2. の結果が真である。

H44: テキストラベルとフォームコントロールを関連付けるために、label 要素を使用する

適用 (対象)

ラベルを用いている HTML 及び XHTML のフォームコントロール

これは、次の達成基準に関連する達成方法である:

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

H44 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、フォームコントロールとラベルを明示的に関連付けるために、label 要素を利用することである。ラベルは、label 要素の for 属性によって特定のフォームコントロールと結びつけることができる。この場合、for 属性値はフォームコントロールの id 属性値と同じでなければならない。

id 属性が name 属性と同じ値で、両方とも指定しなければならない場合でも、その id はそのウェブページ内で一意的なものとして、重複して使用してはならない。

この達成方法は、label 要素が見えているかどうか、つまり CSS で非表示にしているかどうかに関わらず、達成基準 1.1.1、1.3.1、4.1.2 を満たすことができる。しかし、達成基準 3.3.2 の場合、label 要素は、フィールドの目的を理解するのに助けが必要であるすべての人に支援を提供するため、表示しなければならない。

ラベルまたはコントロールをクリックするとコントロールがアクティブなるため、コントロールのクリック可能な領域を大きくすることは、この達成方法の更なるメリットである。これは運動制御が不十分な利用者に役立つ。

input 要素の type="checkbox" と type="radio" では、label 要素をその後に配置することに注意する。

注記 1: 明示的なラベルを利用する要素は次の通りである:

input type="text"
input type="checkbox"
input type="radio"
input type="file"
input type="password"
textarea
select

注記 2: 次の場合には、label 要素は利用しない。これらの要素に対するラベルは、value 属性 (送信ボタン及びリセットボタン)、alt 属性 (画像ボタン)、又は要素それ自体の内容 (汎用ボタン) を介して提供されるからである。

送信及びリセットボタン (input type="submit" 又は input type="reset")
画像ボタン (input type="image")
隠しフィールド (input type="hidden")
スクリプトボタン (button 要素又は input type="button")

訳注: WAIC では H44 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H44 も参照されたい。

事例

事例 1: テキスト入力フィールド

この事例では、テキスト入力フィールドに「First name:」という明示的なラベルが付けてある。label 要素の for 属性値は、input 要素の id 属性値と一致している。

コード例:

<label for="firstname">First name:</label> 
<input type="text" name="firstname" id="firstname" />

事例 2: チェックボックス

コード例:

<input type="checkbox" id="markuplang" name="computerskills" checked="checked">
<label for="markuplang">HTML</label>

事例 3: ラジオボタンのグループ

関連するラジオボタンの小さなグループについて、簡単な説明が付けてあり、さらに個々の要素にラベルが付けてある。

ラジオボタンの数が多く、それらの関連付けや操作説明を必要とする場合は、H71: fieldset 要素及び legend 要素を使用して、フォームコントロールのグループに関する説明を提供するの方法を考慮すべきである。

コード例:

 <h1>Donut Selection</h1>
<p>Choose the type of donut(s) you would like then select 
   the "purchase donuts" button.</p>
<form action="http://example.com/donut" method="post">
<p>
  <input type="radio" name="flavor" id="choc" value="chocolate" />
    <label for="choc">Chocolate</label><br/>
  <input type="radio" name="flavor" id="cream" value="cream"/>
    <label for="cream">Cream Filled</label><br/>
  <input type="radio" name="flavor" id="honey" value="honey"/>
    <label for="honey">Honey Glazed</label><br/>
  <input type="submit" value="Purchase Donuts"/>
</p>
</form>

参考リソース

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

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記は、HTML 5.2§4.10.4. The label element を代わりに参照できる。

検証

手順

ウェブページ内の type="text"、type="file"、又は type="password" を指定した input 要素、textarea 要素、及び select 要素全てについて:

input 要素、textarea 要素又は select 要素の前に、そのコントロールの目的を特定できる label 要素があることを確認する。
label 要素の for 属性が、input 要素、textarea 要素又は select 要素の id と一致している。
label 要素のラベルが表示されていることを確認する。

ウェブページ内の type="checkbox" 及び type="radio" を指定した input 要素全てについて:

input 要素の後に、そのコントロールの目的を特定する label 要素があることを確認する。
label 要素の for 属性が、input 要素の id 属性と一致していることを確認する。
label 要素のラベルが表示されていることを確認する。

期待される結果

1. 及び 2. の結果が真である。達成基準 3.3.2 に関しては、3. の結果も真である。

H45: longdesc 属性を用いる

適用 (対象)

短いテキストによる代替では説明しきれない画像を含む HTML 及び XHTML 文書

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

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

H45 に関するユーザエージェントサポートノートを参照のこと。

解説

訳注: WAIC では H45 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H45 では、「達成不可能」と評価されている。WAIC はウェブ制作者がこの達成方法を使用することを推奨しない。

訳注: WAIC では H45 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H45 も参照されたい。

この達成方法の目的は、短いテキストによる代替では画像の機能や情報が十分に伝達できない場合に、longdesc 属性でのファイル指定によって情報を提供することである。longdesc 属性には URI を指定する。これは非テキストコンテンツの詳しい説明を含む目的地を意味する。

制作者は、テキストを別のリソースまたはページ上の画像にテキストを含めることで、画像の説明を提供できる。別のリソースを用いて説明することの利点は、同じ画像を複数の箇所で簡単に再利用できることにあり、元となるドキュメントにページ上の視覚的なノイズを加えず、説明の最終点を利用者に明確にすることにある。画像と同じページに説明を提供する利点は、すべての利用者が説明にアクセスできることにある。ページ上のメソッドの制限は、複数の説明を単一の別ページに提供することと同様に、現在の longdesc 属性の実装サポートでは、長い説明文の最終点を識別できないということである。制作者はどこで説明文が終わるかを識別する定型文を提供することによって解決ができる。

事例

事例 1: longdesc 属性を用いて別のリソースに含まれた長い説明文を参照する。

コード例:

<p><img src="chart.gif" alt="a complex chart" longdesc="chartdesc.html"/></p>

事例 2: longdesc 属性を用いて同じページに含まれた長い説明文を参照する。

コード例:

<img longdesc="thispage.html#desc" alt="Line graph of the number of subscribers" src="http://www.company/images/graph.png">
<div id="desc">
<h3>Long Description: Line graph of the number of subscribers</h3>
<!-- すべてのグラフ説明文 -->
<p>Long description ends.</p>
<div>

参考リソース

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

検証

手順

longdesc 属性を指定した img 要素があることを確認する。
longdesc 属性の値が、存在するリソースの有効な URI であることを確認する。
その URI で指定されたコンテンツには、関連付けられたオリジナルの非テキストコンテンツの詳しい説明が含まれていることを確認する。

期待される結果

1. から 3. の全ての結果が真である。

H46: `embed` 要素と一緒に `noembed` 要素を用いる

適用 (対象)

embed 要素でプラグインを読み込むドキュメント

これは、次の達成基準に関連する達成方法である:

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

H46 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、embed 要素の代替コンテンツとして noembed を提供することである。noembed 要素は embed 要素がサポートされていない場合のみレンダリングされる。ページのどこにでも配置できるが、embed 要素の子要素として組み込む方が良い。これによりテキストによる代替が embed 要素に関連付けられてことが支援技術にも明らかになる。

訳注: noembed 要素は、以前の HTML のバージョンで標準として定義されておらず、HTML5 で改めて廃止された要素として定義された。MDN の noembed 要素によれば、新規のサイトではこの要素を使用せず、代わりに object 要素の内容として記述するように勧められている。H53: object 要素のボディを使用する (HTML) も参照のこと。

事例

事例 1: noembed 要素が embed 要素の内側にある

コード例:

<embed src="../movies/history_of_rome.mov"
  height="60" width="144" autostart="false">
  <noembed>
    <a href="../transcripts/transcript_history_rome.htm">Transcript of "The history of Rome"</a>
  </noembed>
</embed>

事例 2: noembed 要素が embed 要素のそばにある

コード例:

<embed src="moviename.swf" width="100" height="80"
  pluginspage="http://example.com/shockwave/download/" />
<noembed>
  <img alt="Still from Movie" src="moviename.gif" 
    width="100" height="80" />
</noembed>;

参考リソース

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

(今のところ、なし。)

検証

手順

embed 要素に子 noembed 要素があるかどうかを確認する
embed 要素の直下に noembed 要素があるかどうかを確認する

期待される結果

1. 又は 2. の結果が真である。

H48: リスト又はリンクのグループに、ol 要素、ul 要素、dl 要素を用いる

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

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

H48 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、リスト要素を役割に合わせて適切に利用し、関連する項目のリストを生成することである。ol 要素は順序のあるリストに、ul 要素は順序のないリストに利用する。定義リスト (dl 要素) は、用語とその定義をまとめるのに利用する。このようなマークアップを用いることで、リストを読みやすくできるとはいえ、すべてのリストをリスト要素でマークアップする必要はない。たとえば、文章に含まれるカンマ区切りのリストを、リスト要素でマークアップする必要はない。

リストの関係を示すためではなく、見た目をリストのようにしたいためにマークアップを用いることで、利用者が情報を利用しにくくなる恐れがある。リストのような見た目にする例としては、リスト項目の最初にアスタリスクを付け、br 要素を用いて各リスト項目を分けるといったことが挙げられる。

支援技術の中には、利用者をリストからリストへ、またはリスト項目からリスト項目へと誘導する機能を備えているものがある。スタイルシートを利用すれば、リストという役割の整合性を保ったまま、提示を変更することができる。

リスト構造 (ul / ol) はハイパーリンクをグループ化するのにも役立つ。これが完了すると、スクリーンリーダーがリストの最初の項目からリストの最後までナビゲートする、または次のリストにジャンプするのに役立つ。この選択により、リンクグループをバイパス化することができる。

訳注: WAIC では H48 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H48 も参照されたい。

事例

事例 1: 連続するステップを示すリスト

この事例では、プロセスの連続するステップを示すために順序リスト (ol 要素) を利用している。

コード例:

 <ol>
  <li>Mix eggs and milk in a bowl.</li>
  <li>Add salt and pepper.</li>
</ol>

訳注: WAIC では H48-1 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H48-1 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 2: 材料のリスト

この事例では、お店で購入する品目を順不同リスト (ul 要素) で示している。

コード例:

<ul>
  <li>Milk</li>
  <li>Eggs</li>
  <li>Butter</li>
</ul>

訳注: WAIC では H48-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H48-2 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 3: 言葉とその定義

この事例では、用語とそれを明確にする定義をまとめるのに定義リスト (dl 要素) を利用している。

コード例:

<dl>
  <dt>blink</dt>
  <dd>turn on and off between .5 and 3 times per second
  </dd>
</dl>

訳注: WAIC では H48-3 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H48-3 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 4: 定義リストを用いた連絡先情報

この事例では、定義リストを用いて、対になる関連するアイテムをマークアップしている。対になっているアイテムは、それ自体が論理的に関連したリストである。定義リスト要素の CSS スタイルはブラウザによるサポートが十分ではないため、スタイル目的のためだけに span 要素がマークアップに含められているが、これは必須ではない。

<dl>
<dt><span>name:</span></dt><dd><span>John Doe</span></dd>
<dt><span>tel:</span></dt><dd><span>01-2345678</span></dd>
<dt><span>fax:</span></dt><dd><span>02-3456789</span></dd>
<dt><span>email:</span></dt><dd><span>johndoe@someemail.com</span></dd>
</dl>

以下の CSS スタイルは、対になっているアイテムそれぞれをテーブルのようなレイアウトにして 1 行に並べるために用いることが可能である。

dt, dd{float: left;margin: 0;padding: 0;}
dt{clear:both;font-weight: bold}
dt span{display: inline-block; width: 70px;}
dd span{display: inline-block; margin-right: 5px;}

この事例のサンプルとして、定義リストを用いた連絡先情報のサンプルがある。

事例 5: リストを用いてリンクをグループ化する

この事例では、リンクが ul 要素と li 要素を用いてグループ化されている。

コード例:

<a name="categories" id="categories"></a><h2>Product Categories</h2>
<ul class="navigation">
    <li><a href="kitchen.html">Kitchen</a></li>
    <li><a href="bedbath.html">Bed &amp; Bath</a></li>
    <li><a href="dining.html">Fine Dining</a></li>
    <li><a href="lighting.html">Lighting</a></li>
    <li><a href="storage.html">Storage</a><li>
</ul>

リスト要素のスタイルを指定するのに CSS を使用することが可能で、この達成方法はさまざまなビジュアルデザインで用いることができる。

この CSS では、リストのビュレットとインデントする左側の余白を削除して、各リスト要素を水平に並べている。

コード例:

ul.navigation {
  list-style: none; 
  padding: 0;
}
ul.navigation li {
  display: inline;
}

このスタイルは、リストのビュレットと左側の余白を削除し、リスト項目を横並びのブロックにして表示する。

コード例:

ul.navigation {
 list-style: none; 
 padding: 0;
}
ul.navigation li {
 display: block; 
 float: left;
}

参考リソース

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

HTML 4.01 Unordered lists (UL), ordered lists (OL), and list items (LI)
HTML 4.01 Definition lists: the DL, DT, and DD elements

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記はそれぞれ、HTML 5.2: 4.4. Grouping content を代わりに参照できる。

H40: 記述リストを使用する

検証

手順

リストの視覚表現 (ビュレットがあるかどうかに関わらず) を含んだコンテンツが、順序なしリストとしてマークアップされている。
番号の付いたリストの視覚表現を含んだコンテンツが、順序付きリストとしてマークアップされている。
用語及びその定義をリストという形式で表現する場合、そのコンテンツが定義リストとしてマークアップされていることを確認する。

期待される結果

上記全ての結果が真である。

H49: 強調又は特別なテキストをマークアップするために、セマンティックなマークアップを使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する
注記: この達成方法は、達成基準 1.3.1 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.3.1 を理解するを参照すること。

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

H49 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、プログラムによる解釈が可能にするために、セマンティックマークアップを使用して強調又は特別なテキストをマークアップする方法を示すことである。強調又は特別なテキストをマークアップするためにセマンティックなマークアップを用いることで、その文書に構造を与えることもできる。そうすることで、例えば、ユーザエージェントは、異なるタイプの構造に対して異なる視覚的提示を用いたり、聴覚的提示で異なる声又はピッチを用いたりすることによって、構造を利用者に知覚可能にすることができる。

大部分のユーザエージェントは、セマンティックなマークアップによって特定されたテキストを、ほかとは別の見た目にする。支援技術の中には、セマンティックなマークアップを適切に用いることで、コンテンツの特性を決定するためのメカニズムを提供するものもある。

訳注: WAIC では H49 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H49 も参照されたい。

事例

セマンティックなテキストのレンダリング例を参照。

事例 1

この事例では、テキストの強調に em 要素と strong 要素を利用する方法を示している。em 要素と strong 要素は、構造的な強調を示すのに用意されているものであり、さまざまな形式で描画されうる (フォントスタイルの変更、読み上げ時の抑揚の変更など)。

コード例:

 ...What she <em>really</em> meant to say was, &quot;This is not ok, 
 it is <strong>excellent</strong>&quot;!...

訳注: WAIC では H49-1 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H49-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2

この事例では、長い引用文をマークアップするのに blockquote 要素を利用している。blockquote 要素ではパラグラフ分けが必要となる場合もある。また、参考資料を示すのに cite 要素も利用している。

コード例:

<p>The following is an excerpt from the <cite>The Story of my Life</cite> by Helen Keller</p>
 <blockquote>
   <p>Even in the days before my teacher came, I used to feel along the square stiff boxwood
   hedges, and, guided by the sense of smell, would find the first violets and lilies.  
   There, too, after a fit of temper, I went to find comfort and to hide my hot face 
   in the cool leaves and grass.</p>
 </blockquote>

訳注: WAIC では H49-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H49-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 3

この事例では、短い引用文のマークアップに q 要素を利用している。q 要素を引用符で囲んであるのは、ユーザエージェントの多くがいまだにこの要素をサポートせず、適切に表示しないからである (前述「ユーザエージェント及び支援技術によるサポート」を参照)。引用符の自動生成を抑制するための CSS 規則は、コンテンツ制作者によって提供される引用符に加えて自動的に引用符を生成しないようにして、二重に引用符で囲まれた内容となるのを防ぐために、q 要素をサポートするユーザエージェントに対して提供される。将来、q 要素が広くサポートされるようになれば、引用符を付けたり、ブラウザの引用符生成を避けたりする必要はなくなるだろう。

訳注: MDN の q 要素で示されているように、今日のモダンなブラウザでは、q 要素の周りに自動的に引用符を追加する。

コード例:

q:before { content: ""; } 
q:after { content: ""; }

コード例:

 <p>Helen Keller said, "<q>Self-pity is our worst enemy and if we yield to it, 
we can never do anything good in the world.</q>"</p>

訳注: WAIC では H49-3 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H49-3 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 4

上付き文字と下付き文字を、sup 要素と sub 要素を使って生成している。

コード例:

 <p>Beth received 1<sup>st</sup> place in the 9<sup>th</sup> grade science competition.</p>
<p>The chemical notation for water is H<sub>2</sub>O.</p>

訳注: WAIC では H49-4 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H49-4 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

参考リソース

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

G115: 構造をマークアップするために、セマンティックな要素を使用する

検証

手順

テキストの提示のバリエーションを通して伝えられる情報に関するコンテンツを調べる。
適切なセマンティックマークアップ (em、strong、cite、blockquote、quote、sub など) が、テキストの変化を通じて情報を伝達するテキストをマークアップに用いられていることを確認する。

期待される結果

2. の結果が真である。

H51: 表形式の情報を提示するために、テーブルのマークアップを使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

解説

この達成方法の目的は、利用者がテーブルを見ることができない場合、又は提示形式が変更された場合でも、含まれる情報の関係を保てる方法で、表の情報を提示することである。情報を表として提示すべきと考えられるのは、テキスト、数値、画像、あるいは他のデータの論理関係が (垂直及び水平に) 2 次元で存在するときである。論理関係は列と行で示され、列と行は論理関係が認識できる状態でなければならない。

table 要素は、子要素 tr、th、td といっしょに用いることで、論理関係を認識可能にする。一方、列を整形するのにタブを入れたり、pre 要素を利用するのは、純粋に見た目だけを考えた方法である。利用者がテーブルを見ることができない場合、又は提示形式が変更された場合は、視覚的に暗に示された論理関係は失われてしまう。

単純な表は一般的に列に対して一つのレベルの見出し、及び／又は行に対して一つのレベルの見出しがある。

通常、単純な表では、1 行目の 1 列目は空白または列全体の内容を 1 列目に記述する。1 行目の 1 列目は空白がなく (つまり、"列見出し"を含む)、列全体の内容を記述しており、読者は列と列の間の異なる意味を区別できる。

1 列目の行は、通常では空白ではなく、行全体の内容を記述した"行見出し"を含んでることが多い。読者は行と行の間の異なる意味を区別できる。その他に、1 列目は単純なデータが含まれる。

訳注: WAIC では H51 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H51 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

訳注: WAIC では H51 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H51 も参照されたい。

事例

事例 1: 列見出しと行見出しが付いた簡単なデータテーブルとしてマークアップしたスケジュール表

この事例では、簡単なデータテーブルに table 要素を利用している。1 行目は曜日、1 列目は時間である。これらのセルは th 要素でマークアップしてあり、列見出しが曜日、行見出しが時間という役割になっている。

スクリーンリーダーは、利用者がテーブルを読み進めるとき、対応する見出し情報の変化を読み上げる。それゆえ、スクリーンリーダーの利用者が同じ行を左右に動くときは、(もしあれば) 予定に対応する曜日 (列見出し) の読み上げを、同じ列を上下に移動するときは、対応する時間の読み上げを聞くであろう。

コード例:

 <table>
  <tr>
    <td> </td>
    <th>Monday</th>
    <th>Tuesday</th>
    <th>Wednesday</th>
    <th>Thursday</th>
    <th>Friday</th>
  </tr>
  <tr>
    <th>8:00-9:00</th>
    <td>Meet with Sam</td>
    <td> </td>
    <td> </td>
    <td> </td>
    <td> </td>
  </tr>
  <tr>
    <th>9:00-10:00</th>
    <td> </td>
    <td> </td>
    <td>Doctor Williams</td>
    <td>Sam again</td>
    <td>Leave for San Antonio</td>
  </tr>
</table>

参考リソース

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

HTML 4.01 Table Element
HTML 4.01 Table rows: The TR element
HTML 4.01 Table cells: The TH and TD elements

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記はそれぞれ、HTML 5.2: 4.9. Tabular dataを代わりに参照できる。

検証

手順

表形式の情報があることを確認する。
表形式の情報それぞれについて:
1. 少なくとも table、tr、th、及び td 要素をもつテーブルマークアップが使用されていることを確認する。

期待される結果

上記全ての結果が真である。

H53: `object` 要素のボディを使用する

適用 (対象)

メディアを読み込む object 要素 (HTML 及び XHTML)

これは、次の達成基準に関連する達成方法である:

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

H53 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、object 要素によってレンダリングされるコンテンツに対して、テキストによる代替を提供することである。object 要素のボディは、そのオブジェクトに関する完全なテキストによる代替を提供するのに用いられるか、または追加的な非テキストコンテンツをテキストによる代替とともに含むことがある。

object 要素のフォールバックコンテンツは、ユーザエージェントによってメディアに要素が読み込まれなかった場合、つまり、ユーザエージェントがメディアテクノロジーまたは利用者の指定によるレンダリングできない場合のみ使用可能である。その状況ではフォールバックコンテンツが利用者に提示される。もしメディアがフォールバックコンテンツなしにレンダリングされた場合、メディアは直接アクセスできることが不可欠である。制作者は、適合基準にメディア技術の直接アクセス可能性に頼っておらず、利用者がフォールバックにアクセスできることを予期できるのであれば、達成基準を満たすためにのみこの達成方法に頼ることができる。

事例

事例 1: 長めの説明を含んだオブジェクト

コード例:

 <object classid="http://www.example.com/analogclock.py">
  <p>Here is some text that describes the object and its operation.</p>
</object>

訳注: WAIC では H53-1 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H53-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2: テキストによる代替のある非テキストコンテンツを含んだオブジェクト

コード例:

<object classid="http://www.example.com/animatedlogo.py">
  <img src="staticlogo.gif" alt="Company Name" />
</object>

訳注: WAIC では H53-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H53-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 3: 機能の簡単な説明を含んだ画像オブジェクト

コード例:

<object data="companylogo.gif" type="image/gif">
  <p>Company Name</p>
</object>

訳注: WAIC では H53-3 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H53-3 では、「達成不可能」と評価されている。WAIC はウェブ制作者がこの達成方法を使用することを推奨しない。

事例 4

この例は、情報の代替表現が提供するために object 要素がネストされている事実を利用している。

コード例:

<object classid="java:Press.class" width="500" height="500">
  <object data="Pressure.mpeg" type="video/mpeg">
    <object data="Pressure.gif" type="image/gif">
      As temperature increases, the molecules in the balloon...
    </object>
  </object>
</object>

参考リソース

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

検証

手順

object 要素のボディに、そのオブジェクトのテキストによる代替があることを確認する。

期待される結果

1. の結果が真である。

H54: 単語の定義箇所を特定するために、`dfn` 要素を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.3 (一般的ではない用語)
- クイックリファレンス 3.1.3 (一般的ではない用語)
- 達成基準 3.1.3 (一般的ではない用語)を理解する

解説

この達成方法の目的は、その語句の定義を伴って語句が用いられている箇所のマーク付けに dfn 要素を用いることである。dfn 要素は、囲んだ用語の定義対象であることを示すのに用いる。言い換えれば、その語句がその場所で定義されている場合に、その用語の存在をマーク付けするのである。ただし、用語を囲むのであって、定義を囲むわけではないことに注意すること。この達成方法は、定義方法に関する G112: インラインの定義を使用するとともに用いられる。

事例

事例 1

次のコードは、dfn 要素の使用例である。

コード例:

<p>The Web Content Accessibility Guidelines require that non-text content
has a text alternative. <dfn>Non-text content</dfn> is content that is not a sequence
of characters that can be programmatically determined or where the sequence is
not expressing something in human language; this includes ASCII Art (which is a
pattern of characters), emoticons, leetspeak (which is character substitution), and
images representing text .</p>

参考リソース

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

HTML 4.01 DFN Element

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記は、HTML 5.2§4.5.8. The dfn element を代わりに参照できる。

G112: インラインの定義を使用する

検証

手順

テキストの中で、インラインで定義されている単語、つまり単語の近くの文章に定義が出現するものを全て特定する。
インラインで定義されているそれぞれの単語が、dfn 要素に含まれていることを確認する。

期待される結果

2. の結果が真である。

H56: 入れ子になったテキストの表記方向に伴う問題を解決するために、インライン要素の `dir` 属性を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.2 (意味のある順序)
- クイックリファレンス 1.3.2 (意味のある順序)
- 達成基準 1.3.2 (意味のある順序)を理解する
注記: この達成方法は、達成基準 1.3.2 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.3.2 を理解するを参照すること。

解説

この達成方法の目的は、入れ子になった表記方向が含まれるテキストについて、インライン要素の dir 属性で方向の変化を指定することである。入れ子になったテキストの表記方向とは、たとえば英語のパラグラフで、文章が次々と続いている中にヘブライ語の引用文が含まれるといった、表記方向の異なるテキストが混在したテキストの表記方向のことである。表記方向の異なるテキストが混在し、スペースや句読点が含まれていると、Unicode の双方向アルゴリズムだけでは望ましくない結果になってしまうので、テキストを span 要素や他のインライン要素で囲み、dir 属性を指定する必要がある。この達成方法の考え方は、What you need to know about the bidi algorithm and inline markup で説明されている。

訳注: 上記の「What you need to know about the bidi algorithm and inline markup」は、「Inline markup and bidirectional text in HTML」とタイトルが変更されている。

事例

事例 1

この事例では、ヘブライ語と英語のように、混在したテキストの表記方向を持つ文章で、右から左へと表記すべき入れ子になったテキストの表記方向を明らかにする。引用全体はヘブライ語であり、右から左に表記されるが、「W3C」というテキストとカンマは、次のようにヘブライ語のテキストの左側に (すなわち、後ろに) 現れるべきである:

The title is "פעילות הבינאום, W3C" in Hebrew.

視覚的な順序に基づく ASCII (右から左へ表記するテキストは大文字で、左から右へ表記するテキストは小文字で書く) では、次の通りである:

the title is "w3c ,YTIVITCA NOITAZILANOITANRETNI" in hebrew.

正しく表示するためには、Unicode の双方向アルゴリズムだけでは不十分なため、次に示すように「W3C」というテキストが引用の中で右側に置かれたままである:

The title is "פעילות הבינאום, W3C" in Hebrew.

視覚的な順序に基づく ASCII では、次の通りである:

the title is "YTIVITCA NOITAZILANOITANRETNI, w3c" in hebrew.

次のようにマークアップすることによって、期待する結果が得られる。

コード例:

<p>The title says "<span lang="he" 
dir="rtl"><span dir="rtl">פעילות הבינאום, W3C</span></span>" in Hebrew.</p>

参考リソース

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

H34: インラインでテキストの方向を混在させるために、Unicode の right-to-left mark (RLM) 又は left-to-right mark (LRM) を使用する

検証

手順

文書内のテキストの表記方向を調べる。
テキストの表記方向が右から左である場合、属性の値が "rtl" である、dir 属性を持つ先祖要素を確認する。
テキストの表記方向が左から右である場合、dir 属性を持つ先祖要素がない、又は属性の値が "ltr" である、dir 属性を持つ先祖要素がないことを確認する。

期待される結果

全てのテキストに対して 2. 及び 3. の結果が真である。

H57: html 要素の言語属性を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.1 (ページの言語)
- クイックリファレンス 3.1.1 (ページの言語)
- 達成基準 3.1.1 (ページの言語)を理解する

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

H57 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、html 要素に lang 属性及び (又は) xml:lang 属性を指定することで、文書の初期設定言語を特定することである。

次のようなさまざまな理由から、文書の言語を特定することが重要である:

点字翻訳ソフトウェアでは、制御符号をアクセント付き文字の代わりにすることや、2 級点字の縮約形を誤って生成するのを避けるために制御符号を挿入することができる。
複数の言語をサポートする音声合成装置は、ページの言語に固有な発音及び構文に適応でき、適切な発音とともに適切なアクセントでテキストを話す。
言語をマークアップしておくことは、将来の技術発展に寄与する。たとえば、言語を自分で翻訳できない利用者でも、なじみのない言語を翻訳するマシンを利用できるようになるだろう。
言語をマークアップしておくことは、ユーザエージェントが辞書で定義を提供するのにも役立つ。

HTML 4.01 では、html 要素に lang 属性を指定する。一方、XHTML を text/html として配信する場合には、XHTML 仕様の要求に合致しつつ、HTML との後方互換性を確保するために、html 要素に lang 属性と xml:lang 属性を指定する。XHTML を application/xhtml+xml として配信する場合には、html 要素の xml:lang 属性のみを指定する。lang 属性と xml:lang 属性の双方には、同じ値のみが指定できる。

注記 1: HTML は lang 属性の利用のみを指示しているが、XHTML 1.0 は (経過措置として) 両方の属性を認めており、XHTML 1.1 は xml:lang 属性のみを認めている。

注記 2: lang 属性と xml:lang 属性で指定できる値については、下記の参考リソースで示されている。言語タグでは、その言語を示すために主言語コードを用い、(ハイフン区切りで示す) 任意の副言語コードは言語の異体を示すのに用いる。たとえば、英語は主言語コードでは「en」で示すが、イギリス英語とアメリカ英語は「en-GB」と「en-US」という形で区別できる。この達成方法では、主言語コードの利用が重要である。副言語コードの利用は任意であるが、ある状況では役に立つかもしれない。

訳注 1: HTML 4.01、XHTML 1.0 及び XHTML 1.1 は Superseded Recommendation としてマークされ、廃止された仕様である。

訳注 2: 上記の「主言語コード」及び「副言語コード」は古い HTML に基づいた説明である。現在の HTML に基づいた言語タグの組み立て方については、参考リソースにある「Language tags in HTML and XML」を参照のこと。

訳注 3: 現在の HTML においては、text/html として提供される場合は lang 属性を、application/xhtml+xml として提供される場合は xml:lang 属性をそれぞれ用いればよい。両方の属性を同時に用いてもよいが、その場合は属性値を同じ値にする必要がある。HTML 5.2§3.2.5.2. The lang and xml:lang attributes も参考のこと。

訳注: WAIC では H57 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H57 も参照されたい。

事例

事例 1

この事例では、HTML 文書の内容がフランス語であることを明確にしている。

コード例:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="fr"> 
<head>
  <title>document écrit en français</title>
  <meta http-equiv="content-type" content="text/html; charset=utf-8" />
</head>  
<body>     
	...document écrit en français...   
</body>
</html>

訳注: WAIC では H57-1 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H57-1 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 2

この事例では、text/html というコンテンツタイプの XHTML 1.0 文書の内容がフランス語であることを明確にしている。XHTML 仕様の要求に合致しつつ、HTML との後方互換性を確保するために、lang 属性と xml:lang 属性の両方を指定している。

コード例:

<!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" lang="fr" xml:lang="fr">
<head>
  <title>document écrit en français</title>
  <meta http-equiv="content-type" content="text/html; charset=utf-8" />
</head>
<body> 
...document écrit en français...      
</body>
</html>

訳注: WAIC では H57-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H57-2 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 3

この事例では、application/xhtml+xml というコンテンツタイプの XHTML 1.1 文書の内容がフランス語であることを明確にしている。xml:lang 属性のみを指定している。

コード例:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 
   "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
<head>
  <title>document écrit en français</title>
	<meta http-equiv="content-type" content="application/xhtml+xml; charset=utf-8" />
</head>
<body> 
	...document écrit en français... 
</body>
</html>

訳注: WAIC では H57-3 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H57-3 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

参考リソース

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

H58: 自然言語の変更を指定するために、言語属性を使用する

検証

手順

文書の html 要素を調べる。
html 要素に lang 属性及び／又は xml:lang 属性があることを確認する。
lang 属性及び／又は xml:lang 属性の値が BCP 47: Tags for the Identification of Languages 又はその後継仕様に準拠しており、そのウェブページの主言語を反映していることを確認する。

期待される結果

上記全ての結果が真である。

H58: 自然言語の変更を指定するために、言語属性を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.2 (一部分の言語)
- クイックリファレンス 3.1.2 (一部分の言語)
- 達成基準 3.1.2 (一部分の言語)を理解する

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

H58 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、使用している HTML または XHTML のバージョンに応じて、lang または xml:lang 属性を用いることで、ページ上で用いられている自然言語の変化を明示することである。

HTML 4.01 では、各要素の lang 属性を用いる。text/html として提供される XHTML では、各要素の lang 属性と xml:lang 属性を用いることで XHTML の仕様を満たし、また HTML に対する後方互換性を保持する。application/xhtml+xml として提供される XHTML の場合は、各要素の xml:lang 属性を用いる。

注記: HTML では lang 属性のみを使用できる。XHTML 1.0 では移行措置として両方の属性を使用できる。XHTML 1.1 では xml:lang 属性のみを使用できる。

訳注 1: HTML 4.01、XHTML 1.0 及び XHTML 1.1 は Superseded Recommendation としてマークされ、廃止された仕様である。

訳注 2: 現在の HTML においては、text/html として提供される場合は lang 属性を、application/xhtml+xml として提供される場合は xml:lang 属性をそれぞれ用いればよい。両方の属性を同時に用いてもよいが、その場合は属性値を同じ値にする必要がある。HTML 5.2§3.2.5.2. The lang and xml:lang attributes も参考のこと。

lang 及び xml:lang 属性に指定できる値については、以下に示す参考リソースに示されている。言語タグは、言語を表すプライマリーコードと、その言語が使用される地域や記述に用いる文字コードなどを表すサブコードから成っている。サブコードの指定は任意で、指定する場合にはプライマリーコードに続けてハイフンを記述し、その後に記述する。たとえば、プライマリーコード「en」は英語を示し、「en-gb」と「en-us」はそれぞれイギリス英語とアメリカ英語を示す。この達成方法において、プライマリーコードの使用は重要である。サブコードの使用は任意だが、状況によっては有用なものになり得る。

訳注: 上記の「プライマリーコード」及び「サブコード」は古い HTML に基づいた説明である。現在の HTML に基づいた言語タグの組み立て方については、参考リソースにある「Language tags in HTML and XML」を参照のこと。

訳注: WAIC では H58 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H58 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例

事例 1

この例では、xml:lang 属性を用いてドイツ語の引用部分を示している。このコードは、lang 属性の使用が許されていない XHTML 1.1 に含むことができるように書かれている。

コード例:

<blockquote xml:lang="de">
  <p>
    Da dachte der Herr daran, ihn aus dem Futter zu schaffen,
    aber der Esel merkte, daß kein guter Wind wehte, lief fort
    und machte sich auf den Weg nach Bremen: dort, meinte er,
    könnte er ja Stadtmusikant werden.
  </p>
</blockquote>

参考リソース

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

H57: html 要素の言語属性を使用する

検証

手順

ドキュメントにおける各要素について:

要素のコンテンツの自然言語が、HTML 4.01, Inheritance of language codes で指定されているように、要素に継承されている言語と同一であることを確認する

ドキュメントにおける各 lang 属性について:

lang 属性の値が BCP 47: Tags for the Identification of Languages 又はその後継に適合していることを確認する

ドキュメントにおける各 xml:lang 属性について:

xml:lang 属性の値が BCP 47: Tags for the Identification of Languages 又はその後継に適合していることを確認する

期待される結果

上記の全ての結果が真である。

H59: link 要素及びナビゲーションツールを使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

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

H59 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、link 要素を用いて、ある HTML ページがウェブページ一式の中でどのような位置にあるのかを示すメタデータを提供する方法、及び利用者がウェブページ一式の中で特定のコンテンツを発見することを支援する方法について解説することである。rel 属性の値が、どのような関係性が定義されているのかを示し、href 属性がその関係を持つドキュメントへのリンクを提供する。複数の link 要素を用いることで、複数の関係を示すこともできる。rel 属性の値としては、以下のようなものが有用である:

Start: 複数のドキュメントの中の最初のドキュメントへのリンク
Next: 一連のドキュメントにおける次のドキュメントへのリンク
Prev: 一連のドキュメントにおける前のドキュメントへのリンク
Contents: 目次の役割を果たすドキュメントへのリンク
Index: 現在のドキュメントに対して索引を提供するドキュメントへのリンク

事例

事例 1

オンライン書籍の第 2 章のウェブページがあり、head 要素セクションに次のリンクが含まれている。

コード例:

<link rel="Contents" href="Contents.html" title="目次"  />
<link rel="Index" href="Index.html" title="索引" />
<link rel="Prev" href="Chapter01.html" title="01. なぜ進んでやるのか？" />
<link rel="Next" href="Chapter03.html" title="03. 誰が進んでやるのか？" />

参考リソース

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

HTML 4.01 LINK element
HTML 4.01 link types
Link Toolbar extension for Firefox
Use <link>s in your document from W3C's Quality Web Tips
LINK - Document Relationship from Web Design Group
The 'link'-Element in (X)HTML

訳注 1: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記はそれぞれ、HTML 5.2§4.2.4. The link element、HTML 5.2§4.8.6. Link types を代わりに参照できる。

訳注 2: 「Link Toolbar extension」は 2018 年現在、最新の Firefox と互換性がないためにインストールできない。

検証

手順

一連のまたは集合的なウェブページにおける、あるウェブページについて:

ナビゲーションに関する全ての link 要素が、その文書の head 要素セクションに含まれている。
その文書の head 要素セクション内のナビゲーションに関する各 link 要素に、少なくとも以下が指定されていることを確認する:
1. リンクタイプを特定するための rel 属性
2. 適切なリソースを見つけるための妥当な href 属性

期待される結果

上記全ての結果が真である。

H60: 用語集にリンクするために、link 要素を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

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

H60 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、用語集の場所を示すメカニズムを提供することである。コンテンツの中にある用語が、別の用語集ページで定義されている場合、用語集を用いるドキュメントの head 要素の範囲内に link 要素を指定することで、その用語集が参照できる。link 要素の rel 属性に「glossary」という値を指定し、href 属性には用語集ページの URI を指定する。これで、利用者が素早く簡単に用語集にアクセスするのをユーザエージェントが支援できるようになる。

事例

事例 1: WCAG 2.0 の用語集

コード例:

<link rel="glossary" href="http://www.w3.org/TR/WCAG20/#glossary">

参考リソース

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

HTML 4.01 LINK element
HTML 4.01 link types
Use <link>s in your document from W3C's Quality Web Tips
LINK - Document Relationship from Web Design Group

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記はそれぞれ、HTML 5.2§4.2.4. The link element、HTML 5.2§4.8.6. Link types を代わりに参照できる。

(今のところ、なし。)

検証

手順

用語集の役割を果たしている、単語と定義のあらゆる組み合わせについて:

用語集で定義した単語、語句又は略語を含むウェブページの head 要素セクションに、link 要素が含まれていることを確認する。
link 要素が rel="glossary" 属性であることを確認する。
link 要素の href 属性が、用語集ページを参照していることを確認する。

期待される結果

上記全ての結果が真である。

注記: WCAG で用いている略語の定義は、「単語、語句、又は名称の短縮形で、その略語が言語の一部になっていないもの。」である。

H62: ruby 要素を使用する

適用 (対象)

XHTML 1.1 及び HTML5

訳注: XHTML 1.1 は Superseded Recommendation としてマークされ、廃止された仕様である。

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.6 (発音)
- クイックリファレンス 3.1.6 (発音)
- 達成基準 3.1.6 (発音)を理解する

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

H62 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、読み方の情報、及び意味が読み方によって決まる場合の連続するテキストの意味に関する情報を提供するために、ルビを振ることである。

多くの言語では、連続するテキストが読み方によって意味が異なる場合がある。これは、ヘブライ語、アラビア語、ほかの諸言語と同様に東アジア言語によくある。また、英語など西ヨーロッパ言語でも起こる。

「Ruby Annotation」は XHTML 1.1 のモジュールのひとつとして定義されている。コンテンツ制作者は「Ruby Annotation」によって、読み方や、場合によっては定義を提供すべく、「ベーステキスト」に注釈を加えることができる。日本語など東アジア言語のテキストでは、ルビが当たり前に利用される。

ルビのマークアップには単純と複雑の 2 種類がある。単純なルビのマークアップは完全な言葉やフレーズのようなテキストの実行が適用される。これは"ベース"テキスト (rb 要素) として知られている。ルビの注釈はどのように読むか示す用語 (rt 要素、または Ruby テキスト) を小さなフォントで表示している。("ルビ"という用語は、印刷でこの目的のために使用される小さい活字が由来)。ルビのテキストは通常、ベーステキストの上または直前に、つまり、横書きのテキストでは直上、縦書きのテキストでは右にレンダリングされる。日本語では、テキストの意味を提供するために、読み方のルビに対して (視覚的に) ベーステキストの反対側に、ルビを用いることもある。また、単純なルビのマークアップでは、ルビのマークアップをサポートしていないユーザエージェント (つまり、XHTML 1.1 又は HTML5 をサポートしていないユーザエージェント) のために、"フォールバック"オプションを提供している。

複合ルビマークアップでは、ベーステキストを小さな単位に分け、ルビ注釈を別々に関連づけることができる。複合ルビマークアップではフォールバックオプションはサポートされない。

読み方を伝える発音区別符号が Unicode フォントに含まれているヘブライ語などの言語では、ルビが用いられるのは稀である。また、英語やヨーロッパ言語でも珍しい。

注記: ルビ又は他の方法によって読み方を示す主な理由は、読み方さえ提供されていれば、コンテンツの書かれた言語を読み、理解することが可能な、障害のある利用者がコンテンツにアクセスできるようにするためである。ただし、そのコンテンツが書かれている言語に馴染みがない利用者のために、読み方を提供する必要はない。

事例

事例 1: 頭文字語の読み方を提供するルビのマークアップ

この事例では、Web Content Accessibility Guidelines という複数の単語の 1 文字目をとって作った頭文字語 (頭字語) の読み方を提供するために、ルビを用いている。WCAG という文字がルビベース (rb 要素) であり、読み方をルビテキスト (rt 要素) として示す。ルビのカッコを指定する rp 要素は、ルビをサポートしていないユーザエージェントに対して、rt 要素で囲まれたテキストが読み方を提供していることを示すために用いられる。ベーステキストの直後にカッコ付きで読み方を描画する (ルビをサポートしているユーザエージェントでは、カッコは表示されない)。

コード例:

<p>When we talk about these guidelines, we often just call them
  <ruby>
    <rb>WCAG</rb>
    <rp>(</rp>
      <rt>Wuh-KAG</rt>
    <rp>)</rp>
  </ruby>.
</p>

事例 2: 日本語のルビ注釈

次は、日本語の事例である。日本語では漢字の読み (ふりがな) を提供するのにルビが用いられる。ルビのカッコを指定する rp 要素は、読み方を提供する rt 要素のテキスト、つまりルビをサポートしていないユーザエージェントが利用し、ベーステキストの直後にカッコ付きで読み方を描画する (ルビをサポートしているユーザエージェントでは、カッコは表示されない)

コード例:

<p>
  <ruby>
    <rb>慶應大学</rb>
    <rp>(</rp>
    <rt>けいおうだいがく</rt>
    <rp>)</rp>
  </ruby>
</p>

参考リソース

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

G102: 略語の元の語又は説明を提供する

検証

手順

読み方を提供するためにルビ注釈が使用されている、連続するテキストについて:

rb 要素で定義した連続するテキストに、rt 要素で読み方が指定してあることを確認する。
単純ルビマークアップを用いている場合、rp 要素があることを確認し、ルビ注釈をサポートしていないユーザエージェントに対して、rt 要素に囲まれたテキストが読み方を提供している。

期待される結果

1. 及び 2. の結果が真である。

H63: データテーブルで見出しセルとデータセルを関連付けるために、scope 属性を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

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

H63 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、scope 属性を利用して見出しセルとデータセルを関連付けることである。 scope 属性を利用するのは、見出しとして利用するあらゆるセルが及ぶ範囲を明確にするためである。範囲とは、そのセルが行、列、行グループ、列グループのどの見出しであるかを特定するものである。row、col、rowgroup、colgroup という値によって範囲を特定することになる。

事例 1 のように、見出しが 1 行目や 1 列目にない単純なテーブルに対してこの達成方法が利用できる。今日のスクリーンリーダーのサポートを考えると、単純なテーブルについて次の二つの状況が当てはまる場合に、この達成方法の利用が示唆される:

td 要素でマークアップしてあるデータセルが、行見出し又は列見出しとしても機能する場合
th 要素ではなく td 要素でマークアップしてある見出しセルがある場合、コンテンツ制作者は、CSS でコントロールする方法があるがそれを採用せず、th 要素の表示特性を避けるために td 要素でマークアップすることがある。

注記 1: 1 行目や 1 列目に見出しがある単純なテーブルについては、scope 属性を指定せずに th 要素を利用するだけで十分である。

注記 2: 複雑なテーブルについては、H43: データテーブルのデータセルを見出しセルと関連付けるために、id 属性及び headers 属性を使用するの通り、id 属性と headers 属性を利用する。

注記 3: 一つの複雑な表よりも、単純な複数の表を用いて作業するほうが簡単だと思う利用者もいるだろう。制作者は、複雑な表を一つ以上の単純な表に変換できるかどうかを検討したい場合がある。

訳注: WAIC では H63 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H63 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

訳注: WAIC では H63 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H63 も参照されたい。

事例

事例 1: 単純なスケジュール表

次のコード例では、1 列目にテーブルの行番号を示す連番が含まれている。行の中でも重要な値は 2 列目に含まれるため、各セルに scope="row" と指定してある。1 行目のセルは td 要素でマークアップし、これらにも scope="col" と指定してある。

コード例:

 <table border="1">
  <caption>Contact Information</caption>
  <tr>
    <td></td>
    <th scope="col">Name</th>
    <th scope="col">Phone#</th>
    <th scope="col">Fax#</th>
    <th scope="col">City</th>
  </tr><tr>
    <td>1.</td>
    <th scope="row">Joel Garner</th>
    <td>412-212-5421</td>
    <td>412-212-5400</td>
    <td>Pittsburgh</td>
  </tr><tr>
    <td>2.</td>
    <th scope="row">Clive Lloyd</th>
    <td>410-306-1420</td>
    <td>410-306-5400</td>
    <td>Baltimore</td>
  </tr><tr>
    <td>3.</td>
    <th scope="row">Gordon Greenidge</th>
    <td>281-564-6720</td>
    <td>281-511-6600</td>
    <td>Houston</td>
  </tr>
</table>

参考リソース

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

HTML 4.01 Table Cells: scope attribute
HTML 4.01 Table cells: The TH and TD elements
Assistive technology reading tables

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記はそれぞれ、HTML 5.2§4.9.10. The th element を代わりに参照できる。

検証

手順

各データテーブルについて:

th 要素全てに、scope 属性があることを確認する。
他の要素の見出しとしての役割を果たす全ての td 要素に、scope 属性があることを確認する。
全ての scope 属性に、値として row、col、rowgroup、又は colgroup があることを確認する。

期待される結果

上記全ての結果が真である。

H64: frame 要素及び iframe 要素の title 属性を使用する

適用 (対象)

frame 要素又は iframe 要素を用いている HTML 及び XHTML ドキュメント

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.1 (ブロックスキップ)
- クイックリファレンス 2.4.1 (ブロックスキップ)
- 達成基準 2.4.1 (ブロックスキップ)を理解する
注記: この達成方法は、達成基準 2.4.1 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 2.4.1 を理解するを参照すること。
達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- クイックリファレンス 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- 達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )を理解する

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

H64 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、フレームの内容を説明するための、frame 要素又は iframe 要素での title 属性の使用方法を示すことである。title 属性はフレームのラベルを提供するものなので、利用者はどのフレームの中に入ってその詳細を見て回るかどうかを判断できる。title 属性は、フレームセットの中の個々のページ (frame 要素) やインラインフレーム (iframe 要素) のラベルを付けるものではない。

title 属性はフレームにラベルを付けるものであって、文書にラベルを付ける title 要素とは異なることに注意しよう。title 属性は利用者が複数のフレームの間を移動しやすくし、また title 要素は利用者の現在位置を明確にするものであり、双方を提供すべきである。

title 属性を name 属性に置き換えることはできない。title 属性は利用者のためにフレームにラベルを付けるものであるのに対して、name 属性はスクリプトによる操作やウィンドウのターゲットを決めるためにフレームにラベルを付けるものだからである。つまり、name 属性は利用者に提供されるものではなく、title 属性だけがその役割を果たしている。

HTML5 では、frame 要素が廃止されている。iframe 要素は未だに HTML5 仕様の一部である。

事例

事例 1

この事例は、ナビゲーションバーと主要コンテンツを別の文書として読み込んでいるフレームそれぞれを説明するために、frame 要素に title 属性を指定する方法を示している。

コード例:

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>A simple frameset document</title>
  </head>
  <frameset cols="10%, 90%">
    <frame src="nav.html" title="Main menu" />
    <frame src="doc.html" title="Documents" />
    <noframes>
      <body>
        <a href="lib.html" title="Library link">Select to
        go to the electronic library</a>
      </body>
    </noframes>
  </frameset>
</html>

訳注: WAIC では H64-1 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H64-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2

この事例は、インラインフレームの内容を説明するために、iframe 要素に title 属性を指定する方法を示している。さらに、iframe 要素を解釈できない古いブラウザのために、読み込むページへの代替リンクを iframe 要素の内容に含めてある。

コード例:

 <html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>A document using iframe</title>
  </head>
...
<iframe src="banner-ad.html" id="testiframe" 
  name="testiframe" title="Advertisement">
    <a href="banner-ad.html">Advertisement</a>
</iframe>
...
</html>

訳注: WAIC では H64-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H64-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

参考リソース

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

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記に関して、frame 要素は HTML 5.2§11.3.3. Frames で廃止された機能として定義されており、iframe 要素は HTML 5.2§4.7.6. The iframe element を代わりに参照できる。

検証

手順

HTML 又は XHTML のソースコードにある frame 要素及び iframe 要素のそれぞれに、title 属性が存在するかどうかを確認する。
title 属性の値として、そのフレームを特定できるテキストがあることを確認する。

期待される結果

1. 及び 2. の結果が真である。

H65: label 要素を使用できない場合に、フォームコントロールを特定するために、title 属性を使用する

適用 (対象)

value 属性、alt 属性、または要素内容で特定できない HTML 及び XHTML のフォームコントロール

これは、次の達成基準に関連する達成方法である:

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

H65 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、ラベルを付けるのが視覚デザイン上そぐわない場合 (たとえば、ラベルとなりうるテキストが画面上にない場合) や、ラベルを表示することで混乱を引き起こしてしまう場合に、title 属性を利用してフォームコントロールにラベルを付けることである。それによって、ユーザエージェントや支援技術が、title 属性を読み上げることができる。

訳注: WAIC では H65 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H65 も参照されたい。

事例

事例 1: 検索対象を絞り込むプルダウンメニュー

検索フォームで検索対象を絞り込むプルダウンメニューを用いている。そのプルダウンメニューは、検索語を入力するテキストフィールドのすぐそばにある。テキストフィールドとプルダウンメニューの関係は、見た目のデザインを目で見ることができる利用者には明白であり、ラベルを置くスペースはない。そこで、select 要素を特定するのに title 属性を利用している。title 属性はスクリーンリーダーによって読み上げられたり、画面拡大ソフトを使っている利用者にはツールチップとして表示されたりする。

コード例:

<label for="searchTerm">Search for:</label>
<input id="searchTerm" type="text" size="30" value="" name="searchTerm">
<select title="Search in" id="scope">
…
</select>

訳注: WAIC では H65-1 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H65-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2: 電話番号の入力フィールド

ウェブページの中に、アメリカでの電話番号を入力するコントロールがあり、市外局番、市内局番、下 4 桁の三つのフィールドで構成されている。

コード例:

<fieldset><legend>Phone number</legend>
<input id="areaCode" name="areaCode" title="Area Code" 
type="text" size="3" value="" >
<input id="exchange" name="exchange" title="First three digits of phone number" 
type="text" size="3" value="" >
<input id="lastDigits" name="lastDigits" title="Last four digits of phone number" 
type="text" size="4" value="" >
</fieldset>

訳注: WAIC では H65-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H65-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 3: 検索機能

ウェブページに、利用者が検索語を入力できるテキストフィールドと、検索を実行するための「検索」というラベルが付いたボタンがある。フォームコントロールを特定するの title 属性を利用し、ボタンはテキストフィールドの直後に置いてあるので、テキストフィールドに検索語を入力すべきことは利用者にとって明白である。

コード例:


<input type="text" title="Type search term here"/> <input type="submit" value="Search"/>

訳注: WAIC では H65-3 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H65-3 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 4: フォームコントロールのデータテーブル

フォームコントロールのデータテーブルは、各コントロールをそのセルの列ヘッダーと行ヘッダーに関連付ける必要がある。タイトル (またはオフスクリーン LABEL) がないと、フォームをタブで移動しながら補助技術を使用して対応する行/列ヘッダー値を一時停止して調べることは視覚的でない利用者には困難である。

例えば、調査のフォームには質問、同意、未決定、同意しないの四つの列見出しが最初の行にある。これらの行は質問と、三つの列の回答選択に対応する各セルのラジオボタンが含まれている。すべてのラジオボタンの title 属性は、回答選択 (列見出し) と質問のテキスト (行見出し) をハイフンまたはコロンをセパレータとして連結したものである。

参考リソース

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

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記は、HTML 5.2§3.2.5.1. The title attribute を代わりに参照できる。

検証

手順

label 要素に関連付けられていない各フォームコントロールを特定する。
そのコントロールに title 属性が指定されていることを確認する。
title 属性がそのコントロールの目的を特定していることを確認する。

期待される結果

上記全ての結果が真である。

H67: 支援技術が無視すべき画像に対して、img 要素の alt テキストを空にして、title 属性を付与しない

適用 (対象)

画像を読み込む HTML 及び XHTML ドキュメント

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

解説

この達成方法の目的は、支援技術が無視できるように画像をマークアップする方法を示すことである。

title 属性が使用されておらず、代替テキストが空に指定されているなら (例 alt="")、それは画像を無視して差し支えないことを支援技術に示している。

注記: alt 属性を「空」にするのと、alt 属性が指定されていないことは同義ではない。

訳注: WAIC では H67 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H67 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

訳注: WAIC では H67 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H67 も参照されたい。

事例

事例 1

次の画像は、ウェブページに装飾のための画像を挿入するのに使用される。

コード例:

<img src="squiggle.gif" width="20" height="20" alt="" />

参考リソース

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

(今のところ、なし。)

検証

手順

無視すべき各画像に対して、

title 属性がない又は空のいずれかであることを確認する。
alt 属性が存在し、空であることを確認する。

期待される結果

1. 及び 2. の結果が真である。

H69: コンテンツの各セクションの開始位置に見出し要素を提供する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

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

H69 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、コンテンツの構造を伝達するために、セクションごとに見出しを指定することである。見出しのマークアップは、次のように利用されることがある。

メインコンテンツの開始位置を示す
メインコンテンツ領域にあるセクションの見出しをマークアップする
上部又はメインのナビゲーション、左側又はサブのナビゲーション、そしてフッターのナビゲーションなど、さまざまなナビゲーションを含んだセクションを区別する
見出しとして用いられる文字画像をマークアップする
セクションによって利用者がページをナビゲートできるように、または、繰り返される情報のブロックをスキップできるようにする

見出しは論理的な階層を伝えるためにデザインされている。見出しの階層の中のレベルを飛ばすと、文書構造がきちんと検討されなかったのではないか、又は一部の見出しが意味ではなく視覚的な表現を得るために選択されたのではないか、といった印象を与えてしまうかもしれない。著者には見出しを階層的に入れ子にすることが推奨される。見出しが階層的である場合、もっとも重要な情報には最も高い論理レベルが与えられ、下位のセクションにはその後の論理レベルが与えられる (すなわち、h2 は h1 の下位セクションである)。このような種類の見出しを与えることは、コンテンツの全体的な構成を、利用者がより簡単に理解することに役立つ。

見出しは、コンテンツの中の重要なセクションの開始位置を示すものであるため、支援技術のユーザーが適切な見出しまで直接ジャンプしてから、コンテンツを読み始めることができる。これにより、他の方法でそのコンテンツに到達するのに時間を要していた利用者のインタラクションが大幅に速くなる。見出しによって、スクリーンリーダ―を利用する全盲の人や、情報のグループを作る支援技術を利用する認知的な障害のある人、あるいは、コミュニケーション障害や読書のときにスクリーンリーダ―に支援される文盲の人のような、障害者がより簡単に見つけられる情報の塊を作ることができる。

注記: 全ての達成方法は、特別なユーザエージェント (支援技術や特別なプラグインを含む) を必要とする人たちが入手でき、そうした種類のユーザエージェント (例えば、スクリーンリーダ―、あるいは適切にマークアップされたコンテンツのナビゲーションにキーボードが使えるようにするプラグインなど) を利用できることを仮定している。

訳注: WAIC では H69 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H69 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

訳注: WAIC では H69 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H69 も参照されたい。

事例

事例 1

この事例では、各セクションの見出しを h2 要素でマークアップすることによって、検索ページ内の複数のセクションを構成している。

コード例:

<h1>Search Technical Periodicals</h1>
 <h2>Search</h2>
 <form action="search.php">
  <p><label for="searchInput">Enter search topic: </label>
  <input type="text" size="30" id="searchInput">
  <input type="submit" value="Go"></p>
 </form>
 <h2>Available Periodicals</h2>
 <div class="jlinks">
  <a href="pcoder.com">Professional Coder</a> |
  <a href="algo.com">Algorithms</a> |
  <a href="jse.com">Journal of Software Engineering</a>
 </div>
 <h2>Search Results</h2>
 ... search results are returned in this section ...

事例 2: コンテンツ全体の構成を示している見出し

この事例では、ナビゲーションとメインコンテンツを知覚できるように、見出しマークアップを利用している。

コード例:

<!-- ロゴ、バナー画像、検索フォームなど  -->
  <h2>Navigation</h2>
    <ul>
      <li><a href="about.htm">About us</a></li>
      <li><a href="contact.htm">Contact us</a></li>
       ...
    </ul>
  <h2>All about headings</h2>
   <!-- メインコンテンツを構成するテキスト、画像、その他のもの…… -->

事例 3: メインコンテンツ部分にあるコンテンツの構成を示している見出し

HTML 4.01 及び XHTML 1.x において、見出し要素はセクションの先頭をマークするだけであることに注意すること。見出し要素をセクションコンテンツに明示的に関連付けるためのマークアップが存在しないため、次の見出し要素が出現するまで、見出しは後に続くすべてのコンテンツに適用されると見なされる。

コード例:

 <html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Cooking techniques</title>  
  </head>   
  <body>     
    <h1>Cooking techniques</h1>     
    <p>       
      ... some text here ...     
    </p>           
    <h2>Cooking with oil</h2> 
    <p> 
        ... text of the section ...     
    </p>           
    <h2>Cooking with butter</h2>       
    <p>
        ... text of the section ...     
    </p>   
  </body> 
</html>

参考リソース

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

HTML 4.01 H1-H6 elements
Pick a Heading Eric Meyer
WebAIM: Semantic Structure
Heading Tags
Heading navigation in web browsers
Firefox では、以下のプラグインがキーボード操作による見出しナビゲーション機能を提供している:
- Accessibility Evaluation Toolbar
- Heading Navigation Greasemonkey User Script

訳注: 「Accessibility Evaluation Toolbar」は 2018 年現在、最新の Firefox と互換性がないためにインストールできない。

検証

手順

コンテンツが別々のセクションに分けられていることを確認する
そのページの各セクションが見出しで始まることを確認する

期待される結果

達成基準 2.4.1 の場合、2 の結果が真であることをを確認する。
達成基準 2.4.10 の場合、1 及び 2 の結果が真であることを確認する。

H70: 繰り返されているコンテンツのブロックをグループ化するために、frame 要素を使用する

適用 (対象)

フレームを用いている HTML 及び XHTML ドキュメント

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.1 (ブロックスキップ)
- クイックリファレンス 2.4.1 (ブロックスキップ)
- 達成基準 2.4.1 (ブロックスキップ)を理解する
注記: この達成方法は、達成基準 2.4.1 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 2.4.1 を理解するを参照すること。

解説

訳注: WAIC では H70 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H70 では、「達成不可能」と評価されている。WAIC はウェブ制作者がこの達成方法を使用することを推奨しない。

訳注: WAIC では H70 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H70 も参照されたい。

この達成方法の目的は、繰り返しているブロックをグループ化するために、どのようにフレームセットを用いることができるかを示すことである。ユーザエージェント及び支援技術のほとんどが、フレームからフレームへとナビゲートする手段を提供しているため、要素をまとめるのにフレームを使うことによって、繰り返されているコンテンツのブロックを簡単に通過できるメカニズムを提供することができる。ウェブサイトでフレームセットを用いている場合、コンテンツのブロックそれぞれを別々のフレームにまとめられる。そして、繰り返しているコンテンツのブロックを、各ウェブページのフレームセットの中で、同一のフレームに表示させる。さらに、各 flame 要素には、そのフレームの内容を説明する title 属性を指定しなければならない。フレームに適切なタイトルが付いていれば、利用者はフレームのナビゲーション機能を使用してコンテンツのブロック間を簡単に移動することができるようになる。

この達成方法は、ページ内のコンテンツを構成するのに既にフレームセットを用いている場合に適している。フレームセットを用いていないウェブページには、他の達成方法を用いることが望ましい。多くの支援技術利用者は、フレームの扱いに手間がかかるからである。さらに対応が望まれる達成方法 (参考) として、ノーフレーム (noframes 要素) を用いる達成方法が、達成基準 1.1.1 にある。

HTML5 では、frame 要素は廃止されている。

事例

事例 1

次のコード例では、コンテンツを構成するのに二つのフレームを用いている。一つ目のフレームのソースは navigation.html というウェブページであり、ナビゲーションのための HTML が含まれている。このフレームには、ナビゲーションバーであることを特定する title 属性が指定してある。二つ目のフレームはサイトの主要コンテンツであり、main.html がソースである。title 属性に「主要ニュースコンテンツ」とありその機能を特定している。

コード例:

<frameset cols="20%, *">
  <frame src="navigation.html" name="navbar" title="Navigation Bar" />
  <frame src="main.html" name="maincontent" title="Main News Content" />
  <noframes>
    <p>View <a href="noframe.html">no frame version</a>.</p>
  </noframes>
</frameset>

参考リソース

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

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記に関して、frame 要素及び frameset 要素は HTML 5.2§11.3.3. Frames で廃止された機能として定義されている。

H64: frame 要素及び iframe 要素の title 属性を使用する

検証

手順

ウェブページが、フレームを用いてコンテンツを構成している場合:

繰り返されているコンテンツのブロックそれぞれを、別々のフレームにまとめているかどうかを確認する。
繰り返されているコンテンツのフレームそれぞれが、各ページのフレームセット内で同じ場所に出現することを確認する。

期待される結果

1. 及び 2. の結果が真である。

H71: fieldset 要素及び legend 要素を使用して、フォームコントロールのグループに関する説明を提供する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、関連するフォームコントロールをセマンティックにグループ化する方法を提供することである。これによって、利用者はフォームコントロールの関係が理解でき、より早く効率的にフォームを利用できるようになる。

フォームコントロールは、fieldset 要素で囲むことによってグループ化できる。つまり、fieldset 要素内にある全てのフォームコントロールが関連付けられることになる。fieldset 要素内での最初の要素は legend 要素でなければならず、legend 要素はそのグループのラベルや説明を提供するものである。なお、利用者を混乱させてしまう恐れがあるため、コンテンツ制作者は必要以上に fieldsets 要素を入れ子にすることを避けるべきである。

フォームコントロールのグループ化が最も重要なのは、関連するラジオボタンやチェックボックスをまとめるときである。ラジオボタンやチェックボックスは、name 属性で同じ値が指定されている場合に、一組のコントロールとして関連付けられる。これらは、選択肢の中から自由に選択できるセレクトメニューと同じように動作することになるが、セレクトメニューは単一のコントロールであるのに対し、ラジオボタンとチェックボックスは複数のコントロールである点が異なる。それぞれのラジオボタンやチェックボックスの個々のラベルは、そのグループの説明となる文脈を十分に伝えられないことがある。この場合、セマンティックにグループ化しておくことが特に重要であり、それによって単一のコントロールのように簡単に操作できるようになり、またグループの説明を補足することができる。ユーザエージェントは、その説明を提供し、複数のコントロールが同じグループの一部であることを利用者に伝えるために、各コントロールのラベルよりも先に legend 要素の内容を提示することが多い。

ラジオボタンやチェックボックスほどには明確に関連していないコントロールをグループ化することが有用になることがある。たとえば、利用者の住所を入力するフィールドがいくつかに分かれている場合、「住所」という legend 要素を付けてグループ化しておくとよい。

ただし、(単一の名前付きフィールドの値を持つ場合でも) 関連するラジオボタン又はチェックボックスのグループに明らかな指示及び明確な選択肢が含まれている (すなわち、特定の各コントロールに関連付けられた個々のラベルが十分な記述を提供する) 場合、fieldset 及び legend 要素は必須ではない。この場合は、H44: テキストラベルとフォームコントロールを関連付けるために、label 要素を使用するで十分である。

ブラウザの初期状態では、fieldset 要素によってグループ化したコントロール全体を枠で囲むという表示であるため、コンテンツ制作者は fieldset 要素の利用を避けたい場合がある。しかし、このような視覚的なグループ化も有益であり、その状態のままにしておくこと (あるいは、何らかの形で視覚的にグループ化すること) をしっかり検討すべきである。見た目のスタイルについては、CSS で fieldset 要素に対する「border」プロパティを上書きしたり、fieldset 要素に対する「position」プロパティを上書きしたりすることによって変更できる。

訳注: WAIC では H71 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H71 も参照されたい。

事例

事例 1: 選択式のテスト

この事例では、一つの質問に対して五つの解答の中からどれかを選べるテスト項目を示している。解答はそれぞれラジオボタン (input type="radio") で提示されており、fieldset 要素に含めてある。テストの質問内容は legend 要素でタグ付けしてある。

コード例:

<fieldset>
  <legend>The play <cite>Hamlet</cite> was written by:</legend>
  <input type="radio" id="shakesp" name="hamlet" checked="checked" value="a">
  <label for="shakesp">William Shakespeare</label><br />
  <input type="radio" id="kipling" name="hamlet" value="b">
  <label for="kipling">Rudyard Kipling</label><br />
  <input type="radio" id="gbshaw" name="hamlet" value="c">
  <label for="gbshaw">George Bernard Shaw</label><br />
  <input type="radio" id="hem" name="hamlet" value="d">
  <label for="hem">Ernest Hemingway</label><br />
  <input type="radio" id="dickens" name="hamlet" value="e">
  <label for="dickens">Charles Dickens</label>
</fieldset>

訳注: WAIC では H71-1 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H71-1 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 2: チェックボックスのグループ

あるウェブサイトでの利用者プロフィールのページで、利用者が複数のチェックボックスを選んで自分の興味を示せるようになっている。各チェックボックス (input type="checkbox") には、label がある。すべてのチェックボックスは、fieldset 要素に含められており、legend 要素にはチェックボックスのグループ全体の説明がある。

コード例:

<fieldset>
  <legend>I am interested in the following (check all that apply):</legend>
  <input type="checkbox" id="photo" name="interests" value="ph">
  <label for="photo">Photography</label><br />
  <input type="checkbox" id="watercol" name="interests" checked="checked" value="wa">
  <label for="watercol">Watercolor</label><br />
  <input type="checkbox" id="acrylic" name="interests" checked="checked" value="ac">
  <label for="acrylic">Acrylic</label>
  …
</fieldset>

訳注: WAIC では H71-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H71-2 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 3: 同じ名前を付けたフィールドとして送信されるラジオボタン

この事例では、1 人の哲学者を選ぶように利用者に求めている。各ラジオボタンが関連している (同じフィールドとして送信される) ことを示すために「name」属性で同じ値を指定し、見た目としてもグループ化すべき点に注意しよう。また、「name」属性は同じ値であっても、「id」属性はそれぞれ一意的な値でなければならない点にも注意しよう。

コード例:

<form action="http://example.com/vote" method="post">
  <fieldset>
    <legend>Your preferred philosopher</legend>
    <input type="radio" name="philosopher" id="philosopher_socrates" value="socrates"/>
    <label for="philosopher_socrates">Socrates</label>
    <input type="radio" name="philosopher" id="philosopher_plato" value="plato"/>
    <label for="philosopher_plato">Plato</label>
    <input type="radio" name="philosopher" id="philosopher_aristotle" value="aristotle"/>
    <label for="philosopher_aristotle">Aristotle</label>
  </fieldset>
  </form>

注記: 関連するチェックボックスのグループも同じように動作するが、利用者が一つ以上のフィールドを選べる点がラジオボタンとは異なる。

訳注: WAIC では H71-3 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H71-3 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 4: 論理的に関連付けたコントロール

この事例では、居住地と郵送先のフィールドを別々に fieldset 要素でグループ化し、legend 要素で異なる内容を指定している。

コード例:

<form action="http://example.com/adduser" method="post">
   <fieldset>
     <legend>Residential Address</legend>
     <label for="raddress">Address: </label>
     <input type="text" id="raddress" name="raddress" />
     <label for="rzip">Postal/Zip Code: </label>
     <input type="text" id="rzip" name="rzip" />
     ...more residential address information...
   </fieldset>
   <fieldset>
     <legend>Postal Address</legend>
     <label for="paddress">Address: </label>
     <input type="text" id="paddress" name="paddress" />
     <label for="pzip">Postal/Zip Code: </label>
     <input type="text" id="pzip" name="pzip" />
     ...more postal address information...
   </fieldset>
</form>

訳注: WAIC では H71-4 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H71-4 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

参考リソース

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

HTML 4.01 Checkboxes
Accessible Forms using WCAG 2.0

検証

手順

関連するコントロールのグループにおいて、各コントロールの個々のラベルが十分な記述を提供しておらず、追加でグループレベルの記述が必要な場合

論理的に関連している input 要素又は select 要素のグループが、fieldset 要素内に含まれていることを確認する。
各 fieldset 要素には、そのグループの説明を含む legend 要素が指定されていることを確認する。

期待される結果

上記全ての結果が真である。

H73: データテーブルの概要を提供するために、table 要素の summary 属性を使用する

適用 (対象)

HTML 4.01 及び XHTML 1.x

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

解説

この達成方法の目的は、テーブルにどのようにデータがまとめられているかという短い概略や、テーブルをどのように読み進めるかという短い説明を提供することである。table 要素に summary 属性を指定しておくことで、スクリーンリーダーの利用者がこのような情報を入手できるが、視覚的には表示されない。

summary 属性は、テーブルの構造が複雑な場合 (たとえば、行ヘッダーや列ヘッダーが複数組み合わせてある場合や、行グループや列グループが複数ある場合) に有用である。また、summary 属性は、構造は単純でもたくさんの行や列を含んでいるデータテーブルでも役に立つ。

summary 属性は、そのテーブルに caption 要素があるかどうかに関わらず指定できる。両方を用いる場合には、summary 属性の内容が単に caption 要素の繰り返しであってはならない。

注記: HTML5 では、summary 属性は廃止された。支援技術はこの属性を引き続きサポートしているかもしれないし、していないかもしれない。コンテンツ制作者は代替手段を検討し、慎重に使うべきである。

注記: WCAG 2.0 はレイアウトレテーブルの使用を禁止していないが、CSS ベースのレイアウトを推奨している。HTML の table 要素に与えられたセマンティックな意義を守り、コンテンツから提示を分離するというコーディング実務に従うためである。レイアウトテーブルを用いる場合には、summary 属性は使用しないか、値を空にする。レイアウトテーブルの目的は、コンテンツの配置を制御することのみであって、テーブルそのものは利用者から見て「透明 (不可視)」であるべきである。summary 属性がテーブルの存在を示してしまうと、この透明性を「壊して」しまう。なお、レイアウトテーブルに空の summary 属性 (summary="") を指定することは許容範囲である。F46: 達成基準 1.3.1 の失敗例－レイアウトテーブルで、th 要素、caption 要素、又は空ではない summary 属性を使用しているを参照のこと。

事例

事例 1: summary 属性はあるが、caption 要素はないデータテーブル

この事例は、バスの時刻表を表している。summary 属性には、運行系統と目的地、時刻表の利用方法が記述されている。

コード例:

<table summary="Schedule for Route 7 going downtown. Service begins 
at 4:00 AM and ends at midnight. Intersections are listed in the top row. 
Find the intersection closest to your starting point or destination, then read 
down that column to find out what time the bus leaves that intersection.">
  <tr>
    <th scope="col">State & First</th>
    <th scope="col">State & Sixth</th>
    <th scope="col">State & Fifteenth</th>
    <th scope="col">Fifteenth & Morrison</th>
  </tr>
  <tr>
    <td>4:00</td>
    <td>4:05</td>
    <td>4:11</td>
    <td>4:19</td>
  </tr>
  …
</table>

訳注: WAIC では H73-1 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H73-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2: summary 属性と caption 要素の両方があるデータテーブル

この事例では、summary 属性と caption 要素の両方を用いている。caption 要素ではバスの運行系統を特定している。summary 属性には、全盲の利用者が時刻表の利用方法を理解するのに役立つ内容を記述している。スクリーンリーダーは、まず caption 要素を、続いて summary 属性を読み上げる。

コード例:

<table summary="Intersections are listed in row 1. 
Find the intersection closest to your starting point 
or destination, then read down that column to find 
out what time the bus leaves that intersection.  
Service begins at 4:00 AM and ends at midnight.">
  <caption>Route 7 Downtown (Weekdays)</caption>
…
</table>

訳注: WAIC では H73-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H73-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

参考リソース

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

HTML 4.01 summary attribute

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記は、HTML 5.2§11.2. Non-conforming features で不適合な機能として定義されている。

検証

手順

各データテーブルにおいて:

summary 属性がある場合、その summary 属性がテーブルの構造を記述しているか、又は、テーブルの使い方を説明していることを確認する。
データテーブルに summary 属性と caption 要素の両方が存在している場合、summary 属性の内容が単に caption 要素の繰り返しになっていないことを確認する。

期待される結果

1 及び 2 の結果が真である。

H74: 開始タグ及び終了タグを仕様に準じて使用していることを確認する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 4.1.1 (構文解析)
- クイックリファレンス 4.1.1 (構文解析)
- 達成基準 4.1.1 (構文解析)を理解する
注記: この達成方法は、達成基準 4.1.1 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 4.1.1 を理解するを参照すること。

解説

この達成方法の目的は、支援技術がコンテンツを解析するときに生じる (ことで知られている) キーエラーを回避することである。このエラーは、コンテンツが、仕様に準じて用いられていない開始タグや終了タグを含むときに起こる。HTML あるいは XHTML のメカニズムをウェブコンテンツ技術やウェブコンテンツ技術のバージョンを特定するために用いたり、このようなタイプのエラーがないようにウェブページを制作したりすることで回避できる。バリデーターにはコンテンツ開発者が利用可能なものがいくつかあり、バリデーターのレポートではこのようなタイプのエラーが指摘される。この達成方法は、間違って形成された開始タグと終了タグに関連するエラーのみを対象としている。文書型宣言は、この検証では必ずしも必要ではないが、文書型宣言をしておくことでバリデーターを活用しやすくなる。

事例

事例 1: HTML

HTML ページが文書型宣言を含んでいる (!DOCTYPE として示されることが多い)。コンテンツ開発者はオフラインあるいはオンラインでバリデーターを利用できる (下記の参考リソース参照)。バリデーターでは、すべての id 属性の値が一意的で、かつ開始タグと終了タグが仕様に準じて用いられていることをチェックできる。

注記: どの要素が終了タグを必要とするかの仕様が、HTML5 の導入とともに変更された。

事例 2: XHTML

XHTML その他の XML ベースの文書同様に、XHTML 文書は、文書型定義 (DTD) や他のタイプの XML スキーマを参照する。コンテンツ開発者はオンラインあるいはオフラインでバリデーターを利用でき (エディターに組み込まれているバリデーションツールを含む)、開始タグや終了タグが仕様に準じて用いられていることをチェックする。

事例 3: 検証のフレームワークを用いる

ウェブサイトが静的なページではなく、HTML あるいは XHTML のページが動的に生成されるときは、コンテンツ開発者は XHTMLUnit や XML Test Suite あるいは類似のフレームワークを用いて生成される XHTML コードのチェックを行うことができる。

参考リソース

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

Do not forget to add a doctype (W3C Quality Assurance Initiative) は、文書型がどういうもので、なぜそれを用いるべきかについて説明している。
Recommended DTDs to use in your Web document (W3C Quality Assurance Initiative) は、よく用いられる宣言のリストである。
How do I validate my code or check for possible errors? は、フリーエディタの HTML-Kit にある、HTML、CSS 及び XML をチェックするためのツールを説明している。

G134: ウェブページをバリデートするの参考リソースを参照のこと。

(今のところ、なし。)

検証

手順

終了タグが必要なすべての要素に対して、終了タグがあることを確認する。
終了タグが禁止されているすべての要素に対して、終了タグがないことを確認する。
入れ子になっているすべての要素の開始タグと終了タグが正しく入れ子になっていることを確認する。

期待される結果

1. 2. 及び 3. の結果が真である。

H75: ウェブページが well-formed であることを確認する

適用 (対象)

すべての XML ベースのマークアップ言語

これは、次の達成基準に関連する達成方法である:

達成基準 4.1.1 (構文解析)
- クイックリファレンス 4.1.1 (構文解析)
- 達成基準 4.1.1 (構文解析)を理解する

解説

この達成方法の目的は、支援技術がコンテンツを解析するときに生じるエラーを避けることである。well-formed については、文書を XML パーサーを用いてチェックし、バリデーションレポートが well-formed に関するエラーを含んでいるかどうかで確認できる。すべての XML パーサーには、well-formed をチェックし、well-formed に関するエラーが見つかったときは、通常の処理を停止することが要求される (XML パーサーは、バリデーションをサポートしていなくてもよい)。

事例

事例 1

XML ファイルは、文書タイプ宣言、xsi:schemaLocation 属性あるいは他のタイプのスキーマへのリファレンスを含む。コンテンツ開発者は、オンラインあるいはオフラインのバリデーター、XML エディタもしくは XML サポートのある IDE (下記参考リソースを参照) を用いて、well-formed であることをチェックできる。

事例 2

XML ファイルが文書タイプ宣言、xsi:schemaLocation 属性又はスキーマがあるのにスキーマ参照のインストラクションのない処理を含まないとき、関連するスキーマがコマンドラインの指示、ユーザダイアログあるいは (構成) コンフィグレーションファイルで指定されている。そして、XML ファイルがスキーマに対してチェックされている。

事例 3

XML ファイルが文書タイプ宣言、xsi:schemaLocation 属性あるいはスキーマがあるのにスキーマ参照のインストラクションのない処理を含まないとき、名前空間がスキーマ文書又は RDDL (Resource Directory Description Language) を読み出すのに参照されておらず、そして XML ファイルがスキーマに対してチェックされている。

事例 4

ウェブサイトが静的な文書ではなく、XML を動的に生成するとき、コンテンツ開発者は XMLUnit や XML Test Suite あるいは類似のフレームワークを用いて、生成される XML コードをチェックできる。

参考リソース

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

Well-Formed XML Documents in Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation 04 February 2004.
Well-Formed XML Documents in Extensible Markup Language (XML) 1.1, W3C Recommendation 04 February 2004.
4.3.2 Well-Formed Parsed Entities in Extensible Markup Language (XML) 1.1, W3C Recommendation 04 February 2004.

G134: ウェブページをバリデートするの参考リソースを参照のこと。

(今のところ、なし。)

検証

手順

各ファイルを XML パーサーにロードする。
well-formedness エラーがないことを確認する。

期待される結果

2. の結果が真である。

H76: クライアントサイドで瞬間的にリダイレクトするために、meta 要素の refresh を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 3.2.5 (要求による変化)
- クイックリファレンス 3.2.5 (要求による変化)
- 達成基準 3.2.5 (要求による変化)を理解する

解説

この達成方法の目的は、クライアントサイドで利用可能なリダイレクトを、利用者を混乱させることなく用いることである。リダイレクトはサーバーサイドで実装するほうが望ましいが (SVR1: クライアントサイドではなく、サーバーサイドで自動リダイレクトを実装する (SERVER) を参照)、コンテンツ制作者がサーバーサイド技術を管理しているとは限らない。

HTML 及び XHTML では、meta 要素に http-equiv 属性には「Refresh」という値、content 属性の値には「0」(ゼロ秒を意味する) を、ブラウザが要求すべき URI を後に伴って指定することができる。重要なのは、新たなページを読み込む前にコンテンツが表示されるのを避けるために、タイムアウトをゼロに設定することである。リダイレクトのコードを指定したページには、リダイレクトに関する情報のみを含めるべきである。

事例

事例 1

コード例:

 <html xmlns="http://www.w3.org/1999/xhtml">    
  <head>      
    <title>The Tudors</title>      
    <meta http-equiv="refresh" content="0;URL='http://thetudors.example.com/'" />    
  </head>    
  <body> 
    <p>This page has moved to a <a href="http://thetudors.example.com/">
      theTudors.example.com</a>.</p> 
  </body>  
</html>

参考リソース

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

F41: 達成基準 2.2.1、達成基準 2.2.4、及び達成基準 3.2.5 の失敗例－ページを再読み込みするために、meta 要素リフレッシュを使用しているも参照のこと。

G110: クライアントサイドの瞬間的なリダイレクトを使用する

検証

手順

ドキュメント内の meta 要素を全て見つける。
各 meta 要素について、値が "refresh" (大文字と小文字の区別なし) の http-equiv 属性、及び content 属性で 0 より大きい数字、その後に続いて ;'URL=anyURL' (anyURL は、現在のページから置き換えるべき URI を表す) という値が含まれていることを確認する。

期待される結果

2. の結果が偽である。

H77: リンクテキストとそれが含まれているリスト項目とを組み合わせて、リンクの目的を特定する

適用 (対象)

リンクが含まれる全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.4 (リンクの目的 (コンテキスト内) )
- クイックリファレンス 2.4.4 (リンクの目的 (コンテキスト内) )
- 達成基準 2.4.4 (リンクの目的 (コンテキスト内) )を理解する

解説

この達成方法の目的は、リンクとそれを含んでいるリスト項目の文脈から、リンクの目的を特定することである。リンクを含んでいるリスト項目が、先祖要素であるブロックレベル要素の中で最もそのリンクに近い場合、リンクテキストだけでは不明瞭なリンクに文脈を与えることになる。その説明によって、利用者がそのリンクと、そのウェブページ内にある他のリンクとを区別できるようになり、そのリンク先へ移動するかどうかを判断しやすくなる。一般的に、リンクテキストとして単に目的地の URI を示すだけでは、リンク先の説明として不十分であることに注意すべきである。

訳注: WAIC では H77 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H77 も参照されたい。

事例

事例 1

コード例:

<ul>
  <li>
    Check out the video report for last year's 
    <a href="festival.htm">National Folk Festival</a>.
  </li>
  <li>
    <a href="listen.htm">Listen to the instruments</a>
  </li>
  <li>
    Guitar Man: George Golden talks about 
    <a href="mkguitars.htm">making guitars</a>.
  </li>
</ul>

訳注: WAIC では H77-1 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H77-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2: ビデオゲームのダウンロードリスト

コード例:

<ul>
  <li>
    <a href="tomb_raider.htm">Tomb Raider: Legend</a>
    <a href="tomb_raider_images.htm">See Images</a>
    <a href="tomb_raider.mpeg">(Download Demo)</a>
  </li>
  <li>
    <a href="fear_extraction.htm">F.E.A.R. Extraction Point</a>
    <a href="fear_extraction_images.htm">See Images</a>
    <a href="fear_extraction.mpeg">(Download Demo)</a>
  </li>
  <li>
    <a href="call_of_duty.htm">Call of Duty 2</a>
    <a href="call_of_duty_images.htm">See Images</a>
    <a href="call_of_duty.mpeg">(Download Demo)</a>
  </li>
  <li>
    <a href="Warhammer 40K.htm">Warhammer 40K</a>
    <a href="warhammer_40k_images.htm">See Images</a>
    <a href="Warhammer_40k.mpeg">(Download Demo)</a>
  </li>
</ul>

訳注: WAIC では H77-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H77-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

参考リソース

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

検証

手順

コンテンツの中で、この達成方法を利用するリンクそれぞれに対して:

そのリンクがリスト項目の一部であることを確認する。
そのリンクテキストとリスト項目を組み合わせると、リンクの目的が説明されていることを確認する。

期待される結果

上記全ての結果が真である。

H78: リンクテキストとそれが含まれている段落とを組み合わせて、リンクの目的を特定する

適用 (対象)

リンクが含まれる全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.4 (リンクの目的 (コンテキスト内) )
- クイックリファレンス 2.4.4 (リンクの目的 (コンテキスト内) )
- 達成基準 2.4.4 (リンクの目的 (コンテキスト内) )を理解する

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

H78 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、リンクとそれを含んでいるパラグラフの文脈から、リンクの目的を特定することである。リンクを含んでいるパラグラフが、先祖要素であるブロックレベル要素の中で最もそのリンクに近い場合、リンクテキストだけでは不明瞭なリンクに文脈を与えることになる。その説明によって、利用者がそのリンクと、そのウェブページ内にある他のリンクとを区別できるようになり、そのリンク先へ移動するかどうかを判断しやすくなる。一般的に、リンクテキストとして単に目的地の URI を示すだけでは、リンク先の説明として不十分であることに注意すべきである。

訳注: WAIC では H78 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H78 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

訳注: WAIC では H78 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H78 も参照されたい。

事例

事例 1

民族音楽祭のウェブページの告知文。

コード例:

<h3>The final 15</h3>
<p>Coming soon to a town near you...the final 15 in the 
National Folk Festival lineup.
<a href="final15.html">[Read more...]</a>
</p>
<h3>Folk artists get awards</h3>
<p>Performers from the upcoming National Folk Festival receive 
 National Heritage Fellowships. 
 <a href="nheritage.html">[Read more...]</a>
</p>
…

参考リソース

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

検証

手順

コンテンツの中で、この達成方法を用いているリンクそれぞれに対して:

そのリンクが段落の一部であることを確認する。
そのリンクテキストと段落を組み合わせると、リンクの目的が説明されていることを確認する。

期待される結果

上記全ての結果が真である。

H79: リンクテキストとそれが含まれているデータセル及び関連づけられた見出しセルとを組み合わせて、リンクの目的を特定する

適用 (対象)

リンクが含まれる全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.4 (リンクの目的 (コンテキスト内) )
- クイックリファレンス 2.4.4 (リンクの目的 (コンテキスト内) )
- 達成基準 2.4.4 (リンクの目的 (コンテキスト内) )を理解する

解説

この達成方法の目的は、リンクとそれを含んでいるデータテーブルの文脈から、リンクの目的を特定することである。文脈とは、そのリンクを含んでいるテーブルセルと、そのセルに関連付けられたテーブルの見出しセルとの関係を指している。データテーブルの文脈によって、リンクを含んでいるセルが、先祖要素であるブロックレベル要素の中で最もそのリンクに近い場合、リンクテキストだけでは不明瞭なリンクに目的が与えられる。それによって、利用者がそのリンクと、そのウェブページ内にある他のリンクとを区別できるようになり、そのリンク先へ移動するかどうかを判断しやすくなる。リンクテキストとして単に目的地の URI を示すだけでは、障害のある利用者、特に認知障害のある利用者にとってはリンク先の説明として不十分であることに注意すべきである。

訳注: WAIC では H79 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H79 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

訳注: WAIC では H79 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H79 も参照されたい。

事例

事例 1: レンタカー会社の料金比較表

コード例:

 <table>
<tr>
  <th></th>
  <th scope="col">Alamo</th>
  <th scope="col">Budget</th>
  <th scope="col">National</th>
  <th scope="col">Avis</th>
  <th scope="col">Hertz</th>
</tr>
<tr>
  <th scope="row">Economy cars</th>
  <td><a href="econ_ala.htm">$67/day</a></td>
  <td><a href="econ_bud.htm">$68/day</a></td>
  <td><a href="econ_nat.htm">$72/day</a></td>
  <td><a href="econ_av.htm">$74/day</a></td>
  <td><a href="econ_hz.htm">$74/day</a></td>
</tr>
<tr>
  <th scope="row">Compact cars</th>
  <td><a href="comp_ala.htm">$68/day</a></td>
  <td><a href="comp_bud.htm">$69/day</a></td>
  <td><a href="comp_nat.htm">$74/day</a></td>
  <td><a href="comp_av.htm">$76/day</a></td>
  <td><a href="comp_hz.htm">$76/day</a></td>
</tr>
<tr>
  <th scope="row">Mid-sized cars</th>
  <td><a href="mid_ala.htm">$79/day</a></td>
  <td><a href="mid_bud.htm">$80/day</a></td>
  <td><a href="mid_nat.htm">$83/day</a></td>
  <td><a href="mid_av.htm">$85/day</a></td>
  <td><a href="mid_hz.htm">$85/day</a></td>
</tr>
<tr>
  <th scope="row">Full-sized cars</th>
  <td><a href="full_ala.htm">$82/day</a></td>
  <td><a href="full_bud.htm">$83/day</a></td>
  <td><a href="full_nat.htm">$89/day</a></td>
  <td><a href="full_av.htm">$91/day</a></td>
  <td><a href="full_hz.htm">$91/day</a></td>
</tr>
</table>

参考リソース

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

検証

手順

コンテンツの中で、この達成方法を用いているリンクそれぞれに対して:

そのリンクがテーブルセルの中にあることを確認する。
そのリンクテキストと関連付けられたテーブル見出しセルを組み合わせると、リンクの目的が説明されていることを確認する。

期待される結果

上記全ての結果が真である。

H80: リンクテキストと先行する見出し要素とを組み合わせて、リンクの目的を特定する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.4 (リンクの目的 (コンテキスト内) )
- クイックリファレンス 2.4.4 (リンクの目的 (コンテキスト内) )
- 達成基準 2.4.4 (リンクの目的 (コンテキスト内) )を理解する

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

H80 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、リンクとその直前にある見出しの文脈から、リンクの目的を特定することである。直前にある見出しは、リンクテキストだけでは不明瞭なリンクに文脈を提供する。それによって、利用者がそのリンクと、そのウェブページ内にある他のリンクとを区別できるようになり、そのリンク先へ移動するかどうかを判断しやすくなる。

注記: 可能なかぎり、文脈による補足を必要とせずにリンクの目的が特定できるリンクテキストを提供すべきである。

訳注: WAIC では H80 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H80 も参照されたい。

事例

事例 1: 複数のホテルに関する情報のブロック

各ホテルの情報は、ホテル名、概要、地図、写真、案内、お客様レビュー、そして予約フォームへのリンクで構成されている。

コード例:

<h2><a href="royal_palm_hotel.html">Royal Palm Hotel</a></h2>
  <ul class="horizontal">
    <li><a href="royal_palm_hotel_map.html">Map</a></li>
    <li><a href="royal_palm_hotel_photos.html">Photos</a></li>
    <li><a href="hroyal_palm_hotel_directions.html">Directions</a></li>
    <li><a href="royal_palm_hotel_reviews.html">Guest reviews</a></li>
    <li><a href="royal_palm_hotel_book.html">Book now</a></li>
  </ul>
<h2><a href="hotel_three_rivers.html">Hotel Three Rivers</a></h2>
  <ul class="horizontal">
    <li><a href="hotel_three_rivers_map.html">Map</a></li>
    <li><a href="hotel_three_rivers_photos.html">Photos</a></li>
    <li><a href="hotel_three_rivers_directions.html">Directions</a></li>
    <li><a href="hotel_three_rivers_reviews.html">Guest reviews</a></li>
    <li><a href="hotel_three_rivers_book.html">Book now</a></li>
  </ul>

訳注: WAIC では H80-1 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H80-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2: ある文書を三つのファイル形式で提供する場合

コード例:

<h2>Annual Report 2006-2007</h2>
<p> 
  <a href="annrep0607.html">(HTML)</a>&nbsp;
  <a href="annrep0607.pdf">(PDF)</a>&nbsp;
  <a href="annrep0607.rtf">(RTF)</a>
</p>

訳注: WAIC では H80-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H80-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 3: 新聞社のウェブサイト

コード例:

<h2><a href="Stockmarket_05052007.htm>Stock market soars as bullishness prevails</a></h2>
<p>this week was a stellar week for the stock market as investing in gold rose 2%. 
<a href="Stockmarket_05052007.htm>More here</a></p>

訳注: WAIC では H80-3 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H80-3 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

参考リソース

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

検証

手順

コンテンツの中で、この達成方法を用いているリンクそれぞれに対して:

そのリンクに先行する見出し要素を見つける。
そのリンクテキストと見出しを組み合わせると、リンクの目的が説明されていることを確認する。

期待される結果

2.の結果が真である。

H81: リストが入れ子になっている状況で、親のリスト項目と結合したリンクテキストを用いて、入れ子になったリストの中でリンクの目的を特定する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.4 (リンクの目的 (コンテキスト内) )
- クイックリファレンス 2.4.4 (リンクの目的 (コンテキスト内) )
- 達成基準 2.4.4 (リンクの目的 (コンテキスト内) )を理解する

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

H81 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、入れ子になったリストに含まれるリスト項目によって与えられる文脈から、リストの中のリンクの目的を特定することである。このリスト項目によって、リンクテキストだけでは不明瞭なリンクに文脈が与えられることになる。その説明によって、利用者がそのリンクと、そのウェブページ内にある他のリンクとを区別できるようになり、そのリンク先へ移動するかどうかを判断しやすくなる。

現在の支援技術には、親のリスト項目によって与えられる文脈的な情報を照会するコマンドがないため、この達成方法を用いても、利用者はリスト項目ひとつひとつに移動する必要がある。そのため、この達成方法は、非常に長く又は深く入れ子になったリストには適していないことがある。

注記: 可能なかぎり、文脈による補足を必要とせずにリンクの目的が特定できるリンクテキストを提供すべきである。

訳注: WAIC では H81 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H81 も参照されたい。

事例

事例 1: ある文書を三つのファイル形式で提供する場合

コード例:

<ul>
<li>Annual Report 2005-2006
  <ul> 
  <li><a href="annrep0506.html">(HTML)</a></li>
  <li><a href="annrep0506.pdf">(PDF)</a></li>
  <li><a href="annrep0506.rtf">(RTF)</a></li>
  </ul>
</li>
<li>Annual Report 2006-2007
  <ul> 
  <li><a href="annrep0607.html">(HTML)</a></li>
  <li><a href="annrep0607.pdf">(PDF)</a></li>
  <li><a href="annrep0607.rtf">(RTF)</a></li>
  </ul>
</li>
</ul>

訳注: WAIC では H81-1 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H81-1 では、「達成不可能」と評価されている。WAIC はウェブ制作者がこの達成方法を使用することを推奨しない。

事例 2: 複数のホテルに関する情報のブロック

各ホテルの情報は、ホテル名、概要、地図、写真、案内、お客様レビュー、そして予約フォームへのリンクで構成されている。

コード例:

<ul>
<li><a href="royal_palm_hotel.html">Royal Palm Hotel</a>
  <ul class="horizontal">
    <li><a href="royal_palm_hotel_map.html">Map</a></li>
    <li><a href="royal_palm_hotel_photos.html">Photos</a></li>
    <li><a href="hroyal_palm_hotel_directions.html">Directions</a></li>
    <li><a href="royal_palm_hotel_reviews.html">Guest reviews</a></li>
    <li><a href="royal_palm_hotel_book.html">Book now</a></li>
  </ul>
</li>
<li><a href="hotel_three_rivers.html">Hotel Three Rivers</a>
  <ul class="horizontal">
    <li><a href="hotel_three_rivers_map.html">Map</a></li>
    <li><a href="hotel_three_rivers_photos.html">Photos</a></li>
    <li><a href="hotel_three_rivers_directions.html">Directions</a></li>
    <li><a href="hotel_three_rivers_reviews.html">Guest reviews</a></li>
    <li><a href="hotel_three_rivers_book.html">Book now</a></li>
  </ul>
</li>
</ul>

訳注: WAIC では H81-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H81-2 では、「達成不可能」と評価されている。WAIC はウェブ制作者がこの達成方法を使用することを推奨しない。

参考リソース

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

検証

手順

コンテンツの中で、この達成方法を用いているリンクそれぞれに対して:

そのリンクが含まれる ul 要素又は ol 要素を見つける。
そのリスト要素 (ul 、ol) が、li 要素の子孫要素であることを確認する。
その li 要素のテキストとリンクテキストを組み合わせると、リンクの目的が説明されていることを確認する。

期待される結果

上記全ての結果が真である。

H83: 利用者の要求に応じて新しいウィンドウを開くために target 属性を使用して、そのことをリンクテキストで明示する

適用 (対象)

HTML5、HTML 4.01 Transitional 及び XHTML 1.0 Transitional

訳注: HTML4 及び XHTML 1.0 は Superseded Recommendation としてマークされ、廃止された仕様である。

これは、次の達成基準に関連する達成方法である:

達成基準 3.2.5 (要求による変化)
- クイックリファレンス 3.2.5 (要求による変化)
- 達成基準 3.2.5 (要求による変化)を理解する

解説

この達成方法の目的は、利用者が要求していない新しいウィンドウの出現によって、利用者が混乱するのを避けることである。利用者によっては、突然開いた新しいウィンドウによって混乱してしまったり、新しいウィンドウを完全に見逃がしてしまう場合がある。HTML5、HTML 4.01 Transitional 及び XHTML 1.0 Transitional では、新しいウィンドウを開くのに、自動ポップアップの代わりに target 属性を用いることができる (target 属性は、HTML 4.01 Strict と XHTML 1.0 Strict では廃止されている)。注意すべきは、target 属性を用いなければ、利用者が新しいウィンドウを開くべきかどうかを自分で決定できることである。target 属性の利用によって、新しいウィンドウを開くというマシンリーダブルな指示が明確に提供される。ユーザエージェントは、あらかじめ利用者に知らせることができ、新しいウィンドウを開かない設定にすることもできる。支援技術を利用していない利用者のために、リンクテキストからも新しいウィンドウを開くことがわかるようにしておく。

事例

事例 1

次の事例では、新しいウィンドウが開くことが示されたリンクで、target 属性が用いられている。

コード例:

<a href="help.html" target="_blank">Show Help (opens new window)</a>

参考リソース

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

HTML5 target attribute

SCR24: 利用者の要求に応じて新しいウィンドウを開くために、プログレッシブエンハンスメントを使用する

検証

手順

新しいウィンドウが開くかどうか確認するために、ドキュメント内の各リンクを起動させる。
新しいウィンドウを開くリンクに target 属性が指定されていることを確認する。
リンクテキストには、新しいウィンドウが開くことを示す情報が含まれていることを確認する。

期待される結果

2. 及び 3. の結果が真である。

H84: アクションを実行するために、select 要素とともにボタンを使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 3.2.2 (入力時)
- クイックリファレンス 3.2.2 (入力時)
- 達成基準 3.2.2 (入力時)を理解する

解説

この達成方法の目的は、select 要素の値を選択することで意図せずアクションが実行されるのではなく、アクションの実行を利用者が制御できるようにすることである。利用者は、アクションが実行されるとは思わずに、select 要素にどんな値があるのかを調べたり、間違って意図しない値を選んだりするかもしれない。利用者が自分の選択に納得したとき、アクションを実行するボタンを選択できるようにする。

select 要素の選択肢の操作によって (フォームの) コントロールの値が変化する場合、キーボードで select 要素の値を選んでいる利用者に対して特に重要である。

事例

事例 1: カレンダー

あるウェブページでは、利用者が任意の年の任意の月を選ぶと、その月のカレンダーが表示される。利用者が月と年を指定した後に「表示」ボタンを押すことでカレンダーが表示される。この例では、クライアントサイドスクリプティングでアクションを実装している。

コード例:


<label for="month">Month:</label>
<select name="month" id="month">
  <option value="1">January</option>
  <option value="2"> February</option>
  ...
  <option value="12">December</option>
</select> 
<label for="year">Year:</label>
<input type="text" name="year" id="year">
<input type="button" value="Show" onclick = "...">

事例 2: アクションを選ぶ

select 要素は実行可能なアクションのリストを含んでいる。利用者が「実行」というボタンを押すまで、アクションは実行されない。

コード例:


<form action="http://somesite.com/action" method="post">
  <label for="action">Options:</label>
  <select name="action" id="action">
    <option value="help">Help</option>
    <option value="reset">Reset</option>
    <option value="submit">Submit</option>
  </select> 
  <button type="submit" name="submit" value="submit">Do It </button>
</form>

参考リソース

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

Jukka Korpela: Navigational pulldown menus in HTML

検証

手順

それぞれの select 要素/ボタンの要素の組み合わせに対して:

select 要素の選択肢にフォーカスがあたったとき (キーボードフォーカスを含む)、どのアクションも実行されないことを確認する。
ボタンを選択すると、現在の select 要素の値に関連付けられたアクションが実行されることを確認する。

期待される結果

上記全ての結果が真である。

H85: select 要素内の option 要素をグループ化するために、optgroup 要素を使用する

適用 (対象)

利用者の入力項目をまとめている HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

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

H85 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、セレクトメニューの中の選択肢をグループ化することである。セレクトメニューは、複数選択式リストやコンボボックスといった、フォームコントロールの許容値の一組である。セレクトメニューには、関連する選択肢のグループが含まれることがある。単に「ダミー」の選択肢を使ってこれらのグループを区切るのではなく、セマンティンクに特定すべきである。これによって、ユーザエージェントは、グループごとに選択肢を閉じておき、利用者が選択肢を素早く拾い読みできるようにしたり、利用者にとって興味のある選択肢がどのグループに属しているのかを示すことができる。また、長い項目を視覚的に分割して、利用者が簡単に自分が選びたい選択肢を発見することにも役立つ。

HTML では、select 要素は複数選択式リストとコンボボックスの両方の生成に利用される。選択肢それぞれは、option 要素で示される。選択肢をグループ化するには、optgroup 要素の子要素に、関連する option 要素を含める。グループに「label」属性でラベル付けすることで、利用者がそのグループに含まれているものは何か予想できるだろう。

optgroup 要素は select 要素の直接の子要素、option 要素は optgroup 要素の直接の子要素として含めるべきとされる。select 要素では、optgroup 要素に一つだけ option 要素を含めることもできるが、実はこのような利用法がデザインを意図したものでないか、コンテンツ制作者は検討すべきである。optgroup 要素を入れ子にはできないので、select 要素内では 1 段階のグループ化しかできない。

グループ分け情報がリストの理解に不可欠な場合でも、コンテンツ制作者は、optgroup 要素が提供するグループ分け情報をスクリーンリーダーが読み上げなくても理解可能なように option 要素のラベルを定義するとよい。

訳注: WAIC では H85 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H85 も参照されたい。

事例

事例 1

次のコンボボックスは、好きな食べ物のデータをまとめたものである。利用者が好みのものを素早く選択できるように、食べ物の種類によってグループ化してある。

コード例:


<form action="http://example.com/prog/someprog" method="post">
    <label for="food">What is your favorite food?</label>
    <select id="food" name="food">
      <optgroup label="Fruits">
        <option value="1">Apples</option>
        <option value="3">Bananas</option>
        <option value="4">Peaches</option>
        <option value="5">...</option>
      </optgroup>
      <optgroup label="Vegetables">
        <option value="2">Carrots</option>
        <option value="6">Cucumbers</option>
       <option value="7">...</option>
     </optgroup>
     <optgroup label="Baked Goods">
       <option value="8">Apple Pie</option>
       <option value="9">Chocolate Cake</option>
       <option value="10">...</option>
     </optgroup>
   </select>
</form>

訳注: WAIC では H85-1 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H85-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2

次の事例は、複数選択式リストで optrgroup 要素をどのように用いるかを示している。

コード例:


<form action="http://example.com/prog/someprog" method="post">
    <label for="related_techniques"><strong>Related Techniques:</strong></label>
    <select name="related_techniques" id="related_techniques" multiple="multiple" size="10">
  <optgroup label="General Techniques">
    <option value="G1">G1: Adding a link at the top of each page ... </option>
    <option value="G4">G4: Allowing the content to be paused and restarted ... </option>
    <option value="G5">G5: Allowing users to complete an activity without any time... </option>
    <option value="G8">G8: Creating an extended audio description for the ... </option>
    <option value="G9">G9: Creating captions for live synchronized media... </option>
    <option value="G10">G10: Creating components using a technology that ... </option>
  </optgroup>
  <optgroup label="HTML Techniques">
    <option value="H2">H2: Combining adjacent image and text links for the same ... </option>
    <option value="H4">H4: Creating a logical tab order through links, form ... </option>
    <option value="H24">H24: Providing text alternatives for the area ... </option>
  </optgroup>
  <optgroup label="CSS Techniques">
    <option value="C6">C6: Positioning content based on structural markup... </option>
    <option value="C7">C7: Using CSS to hide a portion of the link text... </option>
  </optgroup>
  <optgroup label="SMIL Techniques">
    <option value="SM1">SM1: Adding extended audio description in SMIL 1.0... </option>
    <option value="SM2">SM2: Adding extended audio description in SMIL 2.0... </option>
    <option value="SM6">SM6: Providing audio description in SMIL 1.0... </option>
  </optgroup>
  <optgroup label="ARIA Techniques">
    <option value="ARIA1">ARIA1: Using WAI-ARIA describedby... </option>
    <option value="ARIA2">ARIA2: Identifying required fields with the "required"... </option>
    <option value="ARIA3">ARIA3: Identifying valid range information with "valuemin" ... </option>
  </optgroup>
  <optgroup label="Common Failures">
    <option value="F1">F1: Failure of SC 1.3.2 due to changing the meaning of content by... </option>
    <option value="F2">F2: Failure of SC 1.3.1 due to using changes in text presentation... </option>
    <option value="F3">F3: Failure of SC 1.1.1 due to using CSS to include images  ... </option>
    <option value="F4">F4: Failure of SC 2.2.2 due to using text-decoration:blink ...</option>
  </optgroup>
</select>
</form>

訳注: WAIC では H85-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H85-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

参考リソース

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

検証

手順

選択リストに含まれる選択肢について、関連する選択肢のグループがあるかどうかを確認する。
関連する選択肢のグループがある場合、optgroup 要素でグループ化すべきである。

期待される結果

2.の結果が真である。

H86: ASCII アート、顔文字、及びリート語にテキストによる代替を提供する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

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

H86 に関するユーザエージェントサポートノートを参照のこと。

解説

インターネットでグラフィックが広く用いられるようになる前は、ASCII 文字を並べて絵やグラフを描くことがよくあった。今では ASCII アートはウェブではあまり使われないが、もし使うのであれば、スクリーンリーダーでインターネットにアクセスする全盲の人には全く意味が分からないことを覚えておかなかればならない。ASCII アートを使う場合、その絵が何なのかというテキストによる説明も付けておくべきである。また、その ASCII アートをスキップするリンクを置いておくほうがよい。(ただし、これは必須ではない)。

顔文字は非常に広く利用されている。顔文字は、ASCII 文字を組み合わせて、顔の表情や他の方法にして感情を伝える。ただし、スクリーンリーダーの利用者は意味が分からないかもしれないので、できれば顔文字の代わりに、単純に「笑顔」といった言葉を使ったほうがよい。もし顔文字を使うのであれば、テキストによる代替を指定すべきである。場合によっては、ブログやフォーラムを構築するソフトウェアで、たとえばプラグインを利用して、顔文字に使用している ASCII 文字をテキストによる代替の付いた HTML 画像に自動変換することができる。

リート語は、数字や特殊文字を含むさまざまな文字の組み合わせで標準的な文字を置き換える表記法である。リート語はすでに、インターネット文化や俗語の一部となっており、テキストフィルターやスパムフィルターをあざむくのにしばしば利用される。リート語はスクリーンリーダーを利用する全盲の人が理解できないことがあるため、達成基準 1.1.1 に準拠するにはテキストによる代替の提供が求められる。

注記: この達成方法のサポートは限られているため、コンテンツ制作者はテキストによる代替を提供することが推奨される。

事例

事例 1

以下では、イコール記号に数字の 8、ハイフン、数字の 0 をつなげて「恐怖」を表現する顔文字に対する、3 通りの代替の指定方法を示している。

コード例:


=8-0 (fright)
<abbr title="fright">=8-0</abbr>
<img src="fright.gif" alt="fright"/>

訳注: WAIC では H86-1 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H86-1 では、「達成不可能」と評価されている。WAIC はウェブ制作者がこの達成方法を使用することを推奨しない。

事例 2

この事例では、ASCII アートの前にその絵の説明を付け、ASCII アートをスキップするリンクがある。ASCII アートの事例をスキップして事例 3 へ

コード例:


 Figure 1: ASCII art picture of a butterfly. 
 <a href="#skipbutterfly">Skip ASCII image</a>
                                 
                                                                LLLLLLLLLLL
                                                            __LLLLLLLLLLLLLL
                                                           LLLLLLLLLLLLLLLLL
                                                         _LLLLLLLLLLLLLLLLLL
                                                        LLLLLLLLLLLLLLLLLLLL
                                                      _LLLLLLLLLLLLLLLLLLLLL
                                                      LLLLLLLLLLLLLLLLLLLLLL
                                              L     _LLLLLLLLLLLLLLLLLLLLLLL
                                             LL     LLLLLL~~~LLLLLLLLLLLLLL
                                            _L    _LLLLL      LLLLLLLLLLLLL
                                            L~    LLL~        LLLLLLLLLLLLL
                                           LL   _LLL        _LL   LLLLLLLL
                                          LL    LL~         ~~     ~LLLLLL
                                          L   _LLL_LLLL___         _LLLLLL
                                         LL  LLLLLLLLLLLLLL      LLLLLLLL
                                         L  LLLLLLLLLLLLLLL        LLLLLL
                                        LL LLLLLLLLLLLLLLLL        LLLLL~
                  LLLLLLLL_______       L _LLLLLLLLLLLLLLLL     LLLLLLLL
                         ~~~~~~~LLLLLLLLLLLLLLLLLLLLLLLLL~       LLLLLL
                       ______________LLL  LLLLLLLLLLLLLL ______LLLLLLLLL_
                   LLLLLLLLLLLLLLLLLLLL  LLLLLLLL~~LLLLLLL~~~~~~   ~LLLLLL
             ___LLLLLLLLLL __LLLLLLLLLLLLL LLLLLLLLLLLLL____       _LLLLLL_
          LLLLLLLLLLL~~   LLLLLLLLLLLLLLL   LLLLLLLLLLLLLLLLLL     ~~~LLLLL
      __LLLLLLLLLLL     _LLLLLLLLLLLLLLLLL_  LLLLLLLLLLLLLLLLLL_       LLLLL
     LLLLLLLLLLL~       LLLLLLLLLLLLLLLLLLL   ~L ~~LLLLLLLLLLLLL      LLLLLL
   _LLLLLLLLLLLL       LLLLLLLLLLLLLLLLLLLLL_  LL      LLLLLLLLL   LLLLLLLLL
  LLLLLLLLLLLLL        LLLLLLLLLLLLL~LLLLLL~L   LL       ~~~~~       ~LLLLLL
 LLLLLLLLLLLLLLL__L    LLLLLLLLLLLL_LLLLLLL LL_  LL_            _     LLLLLL
LLLLLLLLLLLLLLLLL~     ~LLLLLLLL~~LLLLLLLL   ~L  ~LLLL          ~L   LLLLLL~
LLLLLLLLLLLLLLLL               _LLLLLLLLLL    LL  LLLLLLL___     LLLLLLLLLL
LLLLLLLLLLLLLLLL              LL~LLLLLLLL~     LL  LLLLLLLLLLLL   LLLLLLL~
LLLLLLLLLLLLLLLL_  __L       _L  LLLLLLLL      LLL_ LLLLLLLLLLLLLLLLLLLLL
 LLLLLLLLLLLLLLLLLLLL        L~  LLLLLLLL      LLLLLLL~LLLLLLLLLLLLLLLL~
  LLLLLLLLLLLLLLLLLLLL___L_ LL   LLLLLLL       LLLL     LLLLLLLLLLLLLL
   ~~LLLLLLLLLLLLLLLLLLLLLLLL     LLLLL~      LLLLL        ~~~~~~~~~
           LLLLLLLLLLLLLLLLLL_ _   LLL       _LLLLL
               ~~~~~~LLLLLLLLLL~             LLLLLL
                         LLLLL              _LLLLLL
                         LLLLL    L     L   LLLLLLL
                          LLLLL__LL    _L__LLLLLLLL
                          LLLLLLLLLL  LLLLLLLLLLLL
                           LLLLLLLLLLLLLLLLLLLLLL
                            ~LLLLLLLLLLLLLLLLL~~
                               LLLLLLLLLLLLL
                                 ~~~~~~~~~
<a name="skipbutterfly></a>

訳注: WAIC では H86-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H86-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 3

以下は、リート語で「Austin Rocks」と書いた例である。

コード例:

<abbr title="Austin Rocks">Au5t1N r0xx0rz</abbr>

訳注: WAIC では H86-3 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H86-3 では、「達成不可能」と評価されている。WAIC はウェブ制作者がこの達成方法を使用することを推奨しない。

検証

手順

そのページを一般的なブラウザで開く。
ASCII アート、顔文字、及び／又はリート語がコンテンツに含まれていることを確認する。
全ての ASCII アート、顔文字、及び／又はリート語の直前又は直後に、テキストによる代替があることを確認する。

期待される結果

3. の結果が真である。

H88: 仕様に準じて HTML を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、HTML 及び XHTML をそれぞれの仕様に準じて用いることである。技術仕様では、そのウェブコンテンツ技術の意味及び機能の適切な取扱方法を定めている。仕様に記述されている通りに HTML 及び XHTML の機能を用いることによって、支援技術を含むユーザエージェントが、コンテンツ制作者の意図通りで互いに相互運用性のある機能を提示することが可能となる。

この文書を記述した時点では、HTML 及び XHTML の妥当なバージョンは、HTML 4.01 及び XHTML 1.0 である。HTML 4.01 は、HTML の最も成熟したバージョンであり、特定のアクセシビリティ機能を提供し、ユーザエージェントによって広くサポートされている。XHTML 1.0 は、HTML 4.01 と同じ機能を提供しているが、XML 構造を用いており、HTML の構造よりも厳密な構文となっている。HTML 及び XHTML の最新バージョンは、まだ未成熟であり、ユーザエージェントにもまだ広くサポートされていないのが現状である。

訳注: HTML4 及び XHTML 1.0 は Superseded Recommendation としてマークされ、廃止された仕様である。2018 年 11 月現在、有効な W3C Recommendation は HTML 5.1 及び HTML 5.2 である。

HTML 及び XHTML を仕様に準じて用いるにあたり、幾つかの留意すべき点がある。

仕様で定められている機能だけを用いる: HTML では、ウェブページで用いることのできる要素、属性及び属性値の一式を定義している。それらには固有のセマンティックな意味を持ち、ユーザエージェントが特定の方法で処理するよう意図されている。しかし、時には、仕様にはない方法がコンテンツ制作の際に一般的に用いられることがある。それが一つのユーザエージェントだけによってサポートされることが、そのきっかけとなることが多い。仕様にはない方法を用いた場合、多くのユーザエージェントはそれを当分の間サポートしなかったり、いつまでもサポートしなかったりする。さらに、標準仕様にない用い方をすると、ユーザエージェントによってそのサポート方法が異なることもある。そして、主流のブラウザと比べ少ないリソースで開発されている支援技術は、有用なサポートを追加する場合でも時間を要するため、アクセシビリティに影響を及ぼすことになる。よって、予期しないアクセシビリティの問題を回避するためにも、コンテンツ制作者は HTML 及び XHTML で定義されていない用法を避けるべきである。
仕様によって規定されている方法で機能を用いる: HTML の仕様では、どのように特定の要素、属性及び属性値をセマンティックに処理し解釈すべきかについて、具体的なガイダンスを提供している。しかし、時には、コンテンツ制作者が仕様ではサポートされていない方法でそれらを用いることがある。例えば、本来のセマンティックなメッセージが伝わることを意図せずに、セマンティックな要素を用いて視覚的な効果を得ることが挙げられる。これは、正確なセマンティック情報を用いて首尾一貫したページを描画しているユーザエージェント及び支援技術に対して混乱を招くことにつながる。あくまで HTML の仕様によって規定されている機能として、HTML の各機能を用いることが重要である。
コンテンツが解析可能であることを確認する: HTML 及び XHTML では、ユーザエージェントによって正しく処理されるためには、コンテンツをどのようにコーディングすべきかも定めている。開始タグ及び終了タグ、属性及び値、要素の入れ子などの構造に関するルールは、意図された文書の表現となるようにユーザエージェントがコンテンツを処理できるようにするためにある。HTML 及び XHTML の仕様における構造のルールに従うことが、仕様に準じてそれらのウェブコンテンツ技術を用いる上で重要なことの一つである。

参考リソース

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

G134: ウェブページをバリデートするの参考リソースを参照のこと。

検証

手順

HTML 又は XHTML の各ページに対して:

ページが、関連する仕様において定義されている要素、属性及び属性値のみを用いていることを確認する。
要素、属性及び値が、関連する仕様によって規定されている方法で用いられていることを確認する。
ページが、関連する仕様のルールに従って、正しく解析可能であることを確認する。

注記: 上記 1. 及び 3. は、ページバリデーションツールを用いて容易に確認することができる。上記 2. は、通常は人間による判断が求められるが、ヒューリスティックな評価ツールを補助的に用いて確認することが可能である。

期待される結果

上記の全ての結果が真である。

H89: コンテキストに応じたヘルプを提供するために、title 属性を使用する

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 3.3.5 (ヘルプ)
- クイックリファレンス 3.3.5 (ヘルプ)
- 達成基準 3.3.5 (ヘルプ)を理解する

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

H89 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、title 属性にヘルプ情報を提供することで、フォームにデータを入力する利用者にコンテキストに応じたヘルプを提供することである。ヘルプは書式情報もしくは入力例を含んでもよい。

注記: 現在のユーザエージェントおよび支援技術は title 属性に含まれた情報を利用者に常には提供しない。title 属性が広範囲にサポートされるまではこの達成方法を単独で利用することは避けるべきである。

訳注: 上記の注記同様、HTML 5.2§3.2.5.1. The title attribute の Warning で述べられているように、多くのユーザエージェントではアクセシブルな形でこの属性を公開しないので、title 属性に依存することを勧めていない。

事例

事例 1

地図検索アプリケーションはラベル"住所:"で構成されるフォームと、入力ボックスと、"地図検索"という値の実行ボタンを提供する。インプットボックスは利用者が入力するアドレス書式の例を title 属性に持つ。

コード例:


<label for="searchAddress">Address: </label>
<input id="searchAddress" type="text" size="30" value="" name="searchAddress" 
 title="Address example: 101 Collins St, Melbourne, Australia" />

事例 2

利用者が請求書をオンラインで支払うことを可能にするフォームでは、利用者は自分の口座番号を入力する必要がある。ラベル「口座番号」がついたインプットボックスは、口座番号の特定に関する情報を提供する　title 属性を持つ。

コード例:


<label for="accNum1">Account number: </label>
<input id="accNum1" type="text" size="10" value="" title="Your account number 
 can be found in the top right-hand corner of your bill." />

検証

手順

テキスト入力を要求しているフォームコントロールを特定する。
各フォームコントロールに明示的に関連付けられたラベルがあることを確認する。
各フォームコントロールがコンテキストに応じたヘルプを title 属性で提供していることを確認する。

期待される結果

上記 2. 及び 3.の結果が真である。

H90: label 要素又は legend 要素を使用して、必須のフォームコントロールを明示する

適用 (対象)

外部ラベルを用いている HTML 及び XHTML のコントロール

これは、次の達成基準に関連する達成方法である:

達成基準 3.3.2 (ラベル又は説明)
- クイックリファレンス 3.3.2 (ラベル又は説明)
- 達成基準 3.3.2 (ラベル又は説明)を理解する
注記: この達成方法は、達成基準 3.3.2 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 3.3.2 を理解するを参照すること。

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

H90 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、ウェブアプリケーションまたはフォームで特定のフォームコントロールが必須項目であることを明確に示すことである。コントロールが必須項目であることを示す記号またはテキストは、label 要素、又は fieldset 要素でグループ化されたコントロールに対する legend 要素を用いて、プログラムが解釈できるようにそのコントロールと関連付ける必要がある。記号が用いられている場合には、事前に利用者にその意味を説明する必要がある。

事例

事例 1: テキストを用いて必須項目であることを示す

以下のコード例にあるテキストフィールドには、明示的なラベル「名前 (必須)」がある。label 要素の for 属性値が、input 要素の id 属性値と合致していて、label 要素でマークアップされたテキストによってそのコントロールが必須項目であることを示している。

コード例:


<label for="firstname">First name (required):</label> 
<input type="text" name="firstname" id="firstname" />

注記: 英語では、必須項目の "required" を略して "req." とするコンテンツ制作者もいるが、この略語は分かりにくいという報告がある。

事例 2: アスタリスクを用いて必須項目であることを示す

以下のコード例にあるテキストフィールドには、必須項目であることを示すアスタリスクを含んだ明示的なラベルがある。アスタリスクの意味をフォームの先頭で定義することが重要である。このコード例では、アスタリスクは abbr 要素内にあって、アスタリスク文字にスタイルを指定できるようになっている。この CSS は、アスタリスク文字は視覚に障害のある利用者にとっては見えづらいため、デフォルトのアスタリスク文字よりもサイズを大きくしている。

コード例:


CSS:
.req {font-size: 150%} 
HTML:
<p> Required fields are marked with an asterisk (<abbr class="req" title="required">*</abbr>).</p>
<form action="http://www.test.com" method="post">
<label for="firstname">First name <abbr class="req" title="required">*</abbr>:</label> 
<input type="text" name="firstname" id="firstname" />

事例 3: 画像を用いて必須項目であることを示す

以下のコード例にあるテキストフィールドには、コントロールが必須項目であることを示す画像を含む明示的なラベルがある。画像の意味をフォームの先頭で定義することが重要である。

コード例:


<p><img src="req_img.gif" alt="Required Control" /> indicates that the form control is required</p>
<form action="http://www.test.com" method="post">
<label for="firstname">First name <img src="req_img.gif" alt="Required Control" />:</label> 
<input type="text" name="firstname" id="firstname" />
...

事例 4: ラジオボタンまたはチェックボックスのグループが必須項目であることを示す

ラジオボタン及びチェックボックスは、個々のラジオボタンやチェックボックスではなく、そのグループ全体で一つの必須項目となるため、他のインタラクティブなコントロールとは異なった扱われかたをする。事例 1〜3 で使用された方法は、ラジオボタン及びチェックボックスに適用されるが、必須状態の表示は、label 要素ではなく legend 要素に配置すべきである。

コード例:


<fieldset>
<legend>I am interested in the following (Required):</legend>
<input type="checkbox" id="photo" name="interests" value="ph">
<label for="photo">Photography</label></br>
<input type="checkbox" id="watercol" name="interests" checked="checked" value="wa">
<label for="watercol">Watercolor</label></br>
<input type="checkbox" id="acrylic" name="interests" checked="checked" value="ac">
<label for="acrylic">Acrylic</label>
…
</fieldset>

参考リソース

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

HTML 4.01 form labels

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記は、HTML 5.2§4.10.4. The label element を代わりに参照できる。

検証

手順

必須項目であるフォームコントロールに対して、必須項目であることがフォームコントロールの label 要素又は legend 要素で示されている。
必須項目であることを示すテキスト以外のものに対して、それを使用しているフォームコントロールの前にその意味が説明されていることを確認する。

期待される結果

上記の全ての結果が真である。

H91: HTML のフォームコントロール及びリンクを使用する

適用 (対象)

HTML のフォームコントロール及びリンク

これは、次の達成基準に関連する達成方法である:

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

H91 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、インタラクティブなユーザインタフェースを構成する要素のキーボード操作及び支援技術との相互運用性を提供するために、標準的な HTML のフォームコントロール及びリンク要素を用いることである。

ユーザエージェントは、HTML のフォームコントロール及びリンクのキーボード操作を提供している。さらに、ユーザエージェントは、フォームコントロール及びリンクを、アクセシビリティ API に結び付けている。支援技術は、アクセシビリティ API を利用して、役割 (role)、識別名 (name)、状態 (state)、値 (value) といった適切なアクセシビリティ情報を抽出し、それらを利用者に提供している。役割は HTML の要素によって提供され、名前はその要素に関連付けられているテキストによって提供される。値及び状態が適切な要素は、複合的なメカニズムを通じて、それらの値及び状態も支援技術に提示している。

必須の属性を通じてテキストがすでにコントロールと関連付けられている場合もある。たとえば、送信ボタンは、button 要素内のテキスト又は画像の「alt」属性を識別名として用いている。フォームコントロールの場合は、label 要素又は「title」属性が用いられる。次の表は、HTML のフォームコントロール及びリンクの役割、識別名、値、状態がどのように決定されるかを示したものである。

HTML 要素	役割 (role)	識別名 (name)	値 (value)	状態 (state)
<a>	リンク	`<a>` 要素の `title` 属性、画像リンクの場合は `alt` 属性。テキストと画像の `alt` 属性を両方が提供されている場合は、両者を結合する。	`href` 属性
<button>	プッシュボタン	`<button>` 要素内のテキスト又は `title` 属性
<fieldset>	グループ化	フィールドセット要素にある `<legend>` 要素内のテキスト
<input type = "button", "submit", or "reset">	プッシュボタン	`value` 属性
<input type = "image">	プッシュボタン	`alt` 属性又は `title` 属性
<input type = "text">	編集可能なテキスト	そのコントロールに関連付けられた `<label>` 要素又は `title` 属性	`value` 属性
<input type = "password">	編集可能なテキスト	そのコントロールに関連付けられた `<label>` 要素又は `title` 属性	値は意図的に隠されている
<input type="file">	編集可能なテキスト	そのコントロールに関連付けられた <label> 要素又は 'title' 属性	'value' 属性
<input type="checkbox">	チェックボックス	そのコントロールに関連付けられた `<label>` 要素又は `title` 属性		`checked` 属性
<input type="radio">	ラジオボタン	そのコントロールに関連付けられた `<label>` 要素又は `title` 属性		`checked` 属性
<select>	リスト	そのコントロールに関連付けられた `<label>` 要素又は `title` 属性	`<option>` 要素の `selected` 属性で「`selected`」と指定
<textarea>	編集可能なテキスト	そのコントロールに関連付けられた `<label>` 要素又は `title` 属性	`<textarea>` 要素内のテキスト

事例

事例 1: リンク

ユーザエージェントは、リンクをナビゲートして選択するメカニズムを提供する。次の各事例では、<a href> により、役割 (role) は "link" となる。<a name> は "link" の役割 (role) を提供しないことに注意する。値 (value) は、href 属性の URI である。

事例 1a

事例 1a では、名前 (name) はリンクの中にあるテキストである。この場合は「Example Site」が該当する。

コード例:

<a href="www.example.com">Example Site</a>

事例 1b

リンクの中にある画像に関する事例 1b では、画像の alt 属性が名前 (name) を提供している。例えば、Microsoft Inspect Objects などのように API を閲覧するツールには、alt 属性を可視化できないものもあるが、支援技術では抽出できる。

コード例:

<a href="www.example.com"><img src="example_logo.gif" alt="Example"></a>

事例 1c

事例 1c では、画像の代替テキストとリンクのテキストを連結するときに自動的に空白文字を挿入しない支援技術もある。テキストをスペースなしで連結すべきでない場合、画像と隣接する単語との間にスペースを挿入して、単語が混ざらないようにするのが最も安全である。

コード例:

<a href="www.example.com"><img src="example_logo.gif" alt="Example"> Text</a>

訳注: WAIC では H91-1c に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: H91-1c では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2: ボタン

HTML では、ボタンを生成するのにさまざまな方法があるが、それらは全て「プッシュボタン」という役割 (role) に位置付けられる。

事例 2a

事例 2a では、button 要素内の「save」というテキストが名前 (name) となる。値 (value) はない。

コード例:

<button>Save</button>

事例 2b

事例 2b では、value 属性を用いて「Save」「Submit」「Reset」という名前 (name) を指定している。

コード例:

<input type="button" value="Save" /> 
<input type="submit" value="Submit" />  
<input type="reset" value="Reset" />

事例 2c

事例 2c では、alt 属性を用いて「save」という名前 (name) を指定している。

コード例:

<input type="image" src="save.gif" alt="save" />

事例 2d

事例 2d では、alt 属性ではなく、title 属性を用いて「save」という名前 (name) を指定している。

コード例:

<input type="image" src="save.gif" title="save" />

事例 2e

事例 2e は、コンテンツ制作者が input 要素の 'alt' 属性と 'title' 属性の両方を指定する場合、ユーザエージェントが名前 (name) をどのように決定するかを明らかにする。この場合、ユーザエージェントは、 'alt' 属性 ("save") を使用して、 'title' 属性を無視する。

コード例:

<input type="image" src="save.gif" alt="save" title="save the file" />

事例 3: 入力フィールド

事例 3a

事例 3a では、入力フィールドが「編集可能テキスト」という役割 (role) を持っている。label 要素の for 属性が、input 要素の id 属性を参照することで、label 要素を input 要素と関連付けている。input 要素の名前 (name) は、label 要素で指定した「Type of fruit」となる。値 (value) は、value 属性の「bananas」となる。

コード例:

<label for="text_1">Type of fruit</label>
<input id="text_1" type="text" value="bananas">

事例 3b

事例 3b では、入力フィールドが事例 3a と同じ役割 (role) を持つが、値 (value) がなく、名前 (name) を title 属性で指定している点が異なる。

コード例:

<input id="text_1" type="text" title="Type of fruit">

事例 4: チェックボックス

事例 4 は、input 要素の type 属性から「チェックボックス」という役割 (role) を持っている。label 要素の for 属性が input 要素の id 属性を参照することで、label 要素を input 要素と関連付けている。input 要素の名前 (name) は、label 要素で指定した「Cheese」となる。状態 (state) は checked 属性で「チェックあり」又は「チェックなし」に設定できる。そのコントロールに対する利用者のインタラクションによって、状態 (state) が変更される。

コード例:

<label for="cb_1">Cheese</label> 
<input id="cb_1" type="checkbox" checked="checked">

事例 5: ラジオボタン

事例 5 は、input 要素の type 属性から「ラジオボタン」という役割 (role) を持っている。input 要素の名前 (name) は、label 要素から与えられる。状態 (state) は、checked 属性によって「チェックあり」又は「チェックなし」に設定できる。状態 (state) は、利用者が変更できる。

コード例:

<input type="radio" name="color" id="r1" checked="checked"/><label for="r1">Red</label>
<input type="radio" name="color" id="r2" /><label for="r2">Blue</label>
<input type="radio" name="color" id="r3" /><label for="r3">Green</label>

事例 6: セレクトメニュー

事例 6a

事例 6a は、select 要素によって「リストボックス」という役割 (role) を持っている。名前 (name) は「Numbers」で、label 要素から与えられている。select 要素に名前 (name) を付け忘れるのは、よくあるエラーの一つである。値 (value) は、selected 属性 (XHTML では値を "selected" と指定) のある option 要素であり、初期値は「Two」ということになる。

コード例:

<label for="s1">Numbers</label>
<select id="s1" size="1">
 <option>One</option>
 <option selected="selected">Two</option>
 <option>Three</option>
</select>

事例 6b

事例 6b では、事例 6a の select 要素と同じ名前 (name)、役割 (role)、値 (value) であるが、名前 (name) を title 属性で指定している点が異なる。この方法は、ラベルを視覚的に表示しないほうがよい場合に用いることができる。

コード例:

<select id="s1" title="Numbers" size="1">
 <option>One</option>
 <option selected="selected">Two</option>
 <option>Three</option>
</select>

事例 7: テキストエリア

事例 7a

事例 7a は、textarea 要素の「編集可能なテキスト」という役割 (role) を持っている。名前 (name) は、label 要素で指定した「Type your speech here」である。値 (value) は、textarea 要素内にある「Four score and seven years ago」である。

コード例:

<label for="ta_1">Type your speech here</label>
<textarea id="ta_1" >Four score and seven years ago</textarea>

事例 7b

事例 7b は、同じ役割 (role) を持ち、名前 (name) は title 属性を用いて指定していて、値 (value) は空である。

コード例:

<textarea id="ta_1" title="Type your speech here" >Four score and seven years ago</textarea>

事例 8: フォームコントロールのグループ化

ラジオボタンのフィールドセット

事例 8 のラジオボタンのフィールドセットには「グループ化」という役割 (role) がある。名前 (name) は legend 要素によって与えられている。

コード例:

<fieldset>
  <legend>Choose a Color:</legend> 
     <input id="red" type="radio" name="color" value="red" /><label for="red">Red</label><br /> 
     <input id="blue" type="radio" name="color" value="blue" /><label for="blue">Blue</label><br /> 
     <input id="green" type="radio" name="color" value="green" /><label for="green">Green</label> 
</fieldset>

参考リソース

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

H44: テキストラベルとフォームコントロールを関連付けるために、label 要素を使用する

検証

手順

HTML のソースコードを調べる。
リンク及びフォーム要素に対して、上記の表で示されているように、名前 (name)、値 (value)、状態 (state) が指定されていることを確認する。

期待される結果

上記 2. の結果が真である。

H93: ウェブページの `id` 属性値が一意的 (ユニーク) であるようにする

適用 (対象)

HTML のウェブページすべて

これは、次の達成基準に関連する達成方法である:

達成基準 4.1.1 (構文解析)
- クイックリファレンス 4.1.1 (構文解析)
- 達成基準 4.1.1 (構文解析)を理解する
注記: この達成方法は、達成基準 4.1.1 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 4.1.1 を理解するを参照すること。

解説

この達成方法の目的は、異なる要素に同一の id 属性値があることによって、支援技術がコンテンツを解析しようとする際に問題が生じるエラーを回避することである。このエラーは、ウェブページに重複した id 属性値がないことを確認することによって回避できる。人的に確認することができるほか、HTML のバージョンを特定するメカニズムを用いて HTML 文書をバリデートすることによって確認することが可能である。コンテンツ制作者が利用できるバリデータがいくつかあり、この種のエラーはバリデーションの結果レポートで言及される。このようなバリデーションに文書型宣言は絶対に必要というわけではないが、文書型宣言を明記することによってバリデータをより容易に使用できるようになる。

事例

事例 1: HTML バリデータ

HTML のウェブページに文書型宣言 (!DOCTYPE 宣言ともよばれる) がある。コンテンツ制作者は、オフラインまたはオンラインのバリデータ (下記の参考リソースを参照) を用いて、あるウェブページで同一の id 属性値が一度だけしか用いられていないことを確認することができる。例えば、W3C のバリデータは、ある id 属性値が 2 回使われているのを発見すると、「ID "X" はすでに定義済みである」というふうにレポートする。

参考リソース

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

その他の参考リソースは、G134: ウェブページをバリデートするを参照のこと。

検証

手順

そのウェブページで、すべての id 属性値が一意であることを確認する。

期待される結果

1. の結果が真である。

H94: 要素には重複した属性がないようにする

適用 (対象)

全ての HTML ページ

これは、次の達成基準に関連する達成方法である:

達成基準 4.1.1 (構文解析)
- クイックリファレンス 4.1.1 (構文解析)
- 達成基準 4.1.1 (構文解析)を理解する
注記: この達成方法は、達成基準 4.1.1 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 4.1.1 を理解するを参照すること。

解説

この達成方法の目的は、同一の要素に重複した属性があることによって、支援技術がコンテンツを解析しようとする際に問題が生じるエラーを回避することである。このエラーは、人的に確認することができるほか、HTML のバージョンを特定するメカニズムを用いて HTML 文書をバリデートすることによって確認することが可能である。コンテンツ制作者が利用できるバリデータがいくつかあり、この種のエラーはバリデーションの結果レポートで言及される。このようなバリデーションに文書型宣言は絶対に必要というわけではないが、文書型宣言を明記することによってバリデータをより容易に使用できるようになる。

事例

事例 1: HTML バリデータ

HTML のウェブページに文書型宣言 (!DOCTYPE 宣言ともよばれる) がある。コンテンツ制作者は、オフラインまたはオンラインのバリデータ (下記の参考リソースを参照) を用いて、あるウェブページで同一の id 属性値が一度だけしか用いられていないことを確認することができる。例えば、W3C のバリデータは、ある要素で同じ属性が 2 回使われているのを発見すると、「"X" 属性が重複している」というふうにレポートする。

参考リソース

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

その他の参考リソースは、G134: ウェブページをバリデートするを参照のこと。

検証

手順

同一の要素で 2 回以上使われている属性がないことを確認する。

期待される結果

1. の結果が真である。

H95: キャプションを提供するために、track 要素を使用する

適用 (対象)

HTML5

これは、次の達成基準に関連する達成方法である:

達成基準 1.2.2 (キャプション (収録済) )
- クイックリファレンス 1.2.2 (キャプション (収録済) )
- 達成基準 1.2.2 (キャプション (収録済) )を理解する

解説

この達成方法の目的は、タイミングを指定したテキストのキャプショントラックを video 要素に指定するために HTML5 track 要素を用いることである。テキストのタイミングのとれたキャプショントラックは、音声が利用できない又は明確に聞こえない場合に適した、会話、効果音、関連する音楽の合図、及びその他の関連する音声情報の転写又は翻訳を含む。

track 要素の src 属性は URL であり、これはテキストトラックデータのアドレスである。

track 要素の kind 属性はタイミングを指定したテキストの情報の種類を指示している。キャプションテキストトラックはダイアログおよび他ビデオを理解するために重要な音声のテキストバージョンを提供している。字幕は発話コンテンツのみを含んでいる。もしほかの音声情報がビデオを理解するために重要なのであれば、字幕トラックは達成基準を満たすために十分ではない。

注記: 一部の領域では、オーディオトラックの表示可能なテキスト表示に「字幕」という用語が使われている。制作者は、kind=captions ではなく、kind=subtitles として、オーディオトラックの言語でタイミングを指定したテキストのトラックをマークアップすることができ、関連するオーディオ情報を追加することある。そのようなタイミングを指定したテキストトラックは達成基準 1.2.2 の要件を満たすつもりであったのに、キャプションを見つけようとする利用者を混乱させる可能性があるので、この状況で字幕を使用することは好事例ではない。

事例

事例 1: 一つの言語におけるキャプション

英語のキャプショントラックを持つ、英語ビデオのための video 要素。キャプションは WebVTT フォーマットで提供されている。

コード例:


			 <video poster="myvideo.png" controls>
				 <source src="myvideo.mp4" srclang="en" type="video/mp4">
				 <track src="myvideo_en.vtt" kind="captions" srclang="en" label="English">
			  </video>

事例 2: 複数の言語におけるキャプション

英語のキャプショントラックを持つ、英語ビデオのための video 要素。キャプションは WebVTT フォーマットで提供されている。

コード例:


			  <video poster="myvideo.png" controls>
				<source src="myvideo.mp4" srclang="en" type="video/mp4">
				<source src="myvideo.webm" srclang="fr" type="video/webm">
				<track src="myvideo_en.vtt" kind="captions" srclang="en" label="English">
				<track src="myvideo_fr.ttml" kind="captions" srclang="fr" label="French">
			  </video>

参考リソース

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

G87: クローズドキャプションを提供する

検証

手順

動画を再生するために用いられる各 video 要素において:

動画の言語で kind キャプションの track 要素を含むことを確認する。

期待される結果

上記 1. の結果が真である。

H96: 音声解説を提供するために、track 要素を使用する

適用 (対象)

HTML5

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、タイミングを指定したテキストの音声解説トラックを video 構成要素に指定するために HTML5 track 要素を用いることである。タイミングの指定されたテキストの音声解説トラックは、視覚的な構成要素が隠れていたり、使えなかったり、使うのに不適であったりしたときの音声合成のための、メディア資源のビデオ構成要素のテキスト記述を含む。ユーザエージェントは視覚的でない方法で、例えばそれらを音声合成することによって、利用者にきっかけを使えるようにする。

track 要素の src 属性は URL であり、これはテキストトラックデータのアドレスである。

音声解説のきっかけは、メディア資源の聴覚的な構成要素で利用可能なギャップに収まる必要がある。トラックキューの時間間隔内に記述テキストを合成するのに十分な時間がない場合、ユーザエージェントはスピーチを切り捨てることがある。これにより、追加可能な補足情報の量が制限される。

ユーザエージェントは、解説が完全に同期するまでビデオを一時停止し、そしてビデオを再開することで拡張音声解説もサポートしうる。

事例

事例 1: 複数言語における音声解説

英語ビデオのための video 要素。音声解説は WebVTT フォーマットで提供されている。

コード例:


			 <video poster="myvideo.png" controls>
				<source src="myvideo.mp4" srclang="en" type="video/mp4">
				<track src="myvideo_en.vtt" kind="descriptions" srclang="en" label="English">
			  </video>

事例 2: 複数言語における音声解説

ビデオに英語とフランス語両方のソース要素を含み、WevVTT (vtt) ファイルフォーマットを使った英語とフランス語の音声解説を持つ video 要素。

コード例:


			 <video poster="myvideo.png" controls>
				<source src="myvideo.mp4" srclang="en" type="video/mp4">
				<source src="myvideo.webm" srclang="fr" type="video/webm">
				<track src="myvideo_en.vtt" kind="descriptions" srclang="en" label="English">
				<track src="myvideo_fr.vtt" kind="descriptions" srclang="fr" label="French">
			  </video>

事例 3: 一つの言語におけるキャプション

音声解説トラックを持つ「グーグル自動走行車」の video。

コード例:


			<video controls tabindex="1">
				<source src="cdgQpa1pUUE.webm" type="video/webm">
				<source src="cdgQpa1pUUE.mp4" type="video/mp4">
				<track id="audesc" src="cdgQpa1pUUE.vtt" kind="descriptions" label="English descriptions" srclang="en-us"></track>
			</video>

参考リソース

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

検証

手順

動画を再生するために用いられる各 video 要素において:

動画の言語で kind 説明の track 要素を含むことを確認する。

期待される結果

上記 1. の結果が真である。

H97: nav 要素を使用して、関連したリンクをグループ化する

適用 (対象)

関係のあるリンクを含む HTML5 文書

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

解説

この達成方法の目的は、HTML5 nav 要素を使ってナビゲーションリンクをグループ化することである。nav 要素は、HTML5 のいくつかの区分される要素の一つである。このマークアップを使うと、スクリーンリーダーのような支援技術の利用者が過去に場所を確認してスキップしたリンクを分類するのが容易になる。セマンティックな構造を使うと、カスタムスタイルシートでそれらの関係性を維持しながらリンクのグループの提示を変更できる。nav 要素がページ上で複数回使用されている場合は、aria-label 又は aria-labelledby 属性を使用してナビゲーショングループを区別する。

リンクのグループ全てを　nav 要素でマークアップする必要は無い。例として、リンクはリストのような他の構造にグループ化されることもあり、またはページの分離されたセクションを表現しない場合 ARIA マークアップを使うこともある。

訳注: WAIC では H97 に関するアクセシビリティサポーテッド（AS）情報を提供している。

2020 年 3 月版のアクセシビリティサポーテッド（AS）情報: H97 も参照されたい。

事例

事例 1: 一つの nav 要素に囲まれたナビゲーションリンク

この例は、アクセシビリティカリキュラムにおけるナビゲーションリンクを分類するために nav 要素を使う。

コード例:


				 <nav>
				    <a href="../webaccessibility.html">Web Accessibility</a>
				    <a href="../docaccessibility.html">Document Accessibility</a>
					<a href="../mobileaccessibility.html">Mobile Accessibility</a>
				 </nav>

事例 2: 多くの nav 要素

この例は、文書中に一つ以上の nav 要素があるときに、ナビゲーション分類を識別するために aria-label 属性と nav 要素を使う。

コード例:


			<nav aria-label="Site menu">
			  <ul>
				  <li>...a list of links site navigation link here ...</li>
			  </ul>
			</nav>
			...
			<article>
			  <nav aria-label="Related links">
				...a list of related links here ...
			  </nav>
			</article>

事例 3: 一般的な多くの nav 要素

以下の例は、同じページに二つ以上のナビゲーションメニューが存在し、ラベルとして参照されうるページ上に既存のテキストが無いという状況での良い事例である。

コード例:


			<nav aria-label="primary">
				<a href="home.html">Home</a>
				<a href="about-us.html">About Us</a>
				<a href="products.html">Products</a>
			</nav>
			<nav aria-label="secondary">
				<a href="adverts.html">Our Advertisers</a>
				<a href="related.html">Related Links</a>
				<a href="subsidiaries.html">Subsidiaries</a>
			</nav>

参考リソース

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

HTML5 nav element

検証

手順

視覚的に寄せ集められておりページのセクションを表現するリンクが nav 要素で囲まれていることを確認する。

期待される結果

上記 1. の結果が真である。

3. CSSの達成方法

C6: 構造を示すマークアップに基づいてコンテンツを配置する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.1 (ブロックスキップ)
- クイックリファレンス 2.4.1 (ブロックスキップ)
- 達成基準 2.4.1 (ブロックスキップ)を理解する
達成基準 1.3.2 (意味のある順序)
- クイックリファレンス 1.3.2 (意味のある順序)
- 達成基準 1.3.2 (意味のある順序)を理解する
注記: この達成方法は、達成基準 1.3.2 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.3.2 を理解するを参照すること。
達成基準 1.4.5 (文字画像)
- クイックリファレンス 1.4.5 (文字画像)
- 達成基準 1.4.5 (文字画像)を理解する
達成基準 1.4.9 (文字画像 (例外なし) )
- クイックリファレンス 1.4.9 (文字画像 (例外なし) )
- 達成基準 1.4.9 (文字画像 (例外なし) )を理解する

解説

この達成方法の目的は、スタイルシートが適用されていない場合でも意味のある提示を維持しながら、スタイルシートを介して視覚的外観をどのように向上させることができるかを示すことである。CSS2 の配置プロパティを使用して、コンテンツを利用者のビューポートの任意の位置に表示できる。構造的な要素を使用することで、スタイルが利用できない場合でもコンテンツの意味を判断できることを保証する。

事例

事例 1

この事例では、コンテンツに対して構造 (定義リスト) を示すマークアップがなされている。そして、コンテンツを段組み形式で表示させるために CSS が使用されている。コンテンツは各クラスの指定でそれぞれの段に絶対配置され、HTML の定義リストを表示する際に dd 要素をインデントするユーザエージェントのデフォルト値を上書きするために、マージンの値を 0 にしている。

表示させるコンテンツは以下の通り:

コード例:


 <div class="box">
  <dl>
    <dt class="menu1">Products</dt>
    <dd class="item1">Telephones</dd>
    <dd class="item2">Computers</dd>
    <dd class="item3">Portable MP3 Players</dd>
    <dt class="menu2">Locations</dt>
    <dd class="item4">Idaho</dd>
    <dd class="item5">Wisconsin</dd>
    </dt>
  </dl>
 </div>

上記要素の配置及び表示指定をする CSS は以下の通り:

コード例:


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

スタイルシートが適用されると、データは「製品」と「所在地」の 2 段組みで表示される。スタイルシートが適用されない場合は、構造と読み上げ順序を保持した状態の定義リストとしてテキストが表示される。

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

検証

手順

CSS で表示位置を調整しているコンテンツに対して:

文書からスタイル情報を取り除く、又はユーザエージェントでスタイルシートを無効にする。
構造的な関係及びコンテンツの意味が保持されていることを確認する。

期待される結果

2. の結果が真である。

C7: リンクテキストの一部を非表示にするために、CSS を使用する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、CSS をサポートするユーザエージェントによって画面に表示されないよう、リンクの一意の機能を記述する追加のテキストを追加し、そして追加のテキストをスタイリングすることによってリンクテキストを補うことである。表示されているリンクテキストの意味を理解するために、その前後の内容も読む必要がある場合、この達成方法を用いることによって、リンクテキストの表示は元の状態のままでありながら、リンクに対する十分な説明を提供することができる。

この達成方法を用いるには、まず、表示させないテキストを対象とする CSS セレクタを作成する。そのセレクタの規則集合では、overflow プロパティの値が hidden に指定された縦横 1 ピクセルのボックスの中にテキストが入るようにし、さらにそのテキストをビューポートの外側に配置する指定を入れる。これによって、テキストは画面上には確実に表示されなくなるが、スクリーンリーダーや点字ディスプレイなどの支援技術に対してはアクセシブルな状態を保持できる。ここで留意すべきは、画面に表示されなくなるだけでなく支援技術に対してもそのテキストを隠してしまうという意図せぬ影響が出る恐れがあるため、この達成方法では visibility:hidden 及び display:none を使用していないことである。

注記 1: リンクテキストを非表示にするこの達成方法は、スクリーンリーダーの利用者や企業のウェブコンテンツ制作者の一部によって支持されている。一部のウェブサイトにおいては効果があることも立証されている。しかし、結果的に説明が冗長になることがある上に、熟練したスクリーンリーダーの利用者にはその冗長な説明の読み上げを制御することを要求することもありうるため、スクリーンリーダーの利用者やアクセシビリティの専門家の中には、一般的な達成方法としてはこれを推奨していない人もいる。WCAG ワーキンググループとしては、同じコンテンツが非表示にしたテキストで繰り返されていないのであれば、この達成方法は有用だと考えている。

注記 2: この達成方法は、適合していないコンテンツ向けの適合している代替版のページで解説されているスタイルスイッチングを行う達成方法との組み合わせで使用することも可能である。詳しい情報については、C29: 適合している代替版を提供するために、スタイルスイッチャーを使用する及び適合している代替版を理解するを参照のこと。

事例

事例 1

この事例は、各記事の概要のあとに「全文」というリンクのあるニュースサイトを示している。非表示にされたリンクテキストが、何の「全文」であるのかを説明している。

コード例:


<?xml version="1.0" encoding="UTF-8"?>
<!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" xml:lang="en" lang="en"> 
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=UTF-8" /> 
<link href="access.css" rel="stylesheet" type="text/css" />
<title>Hidden Link Text</title>
</head>
<body> 
<p>Washington has announced plans to stimulate economic growth.
  <a href="#"> <span>Washington stimulates economic growth </span>
  Full Story</a></p>
</body>
</html>

事例 2

この事例では、異なるフォーマットの電子ブックが用意されている場合について説明している。「HTML」「PDF」といったリンクのテキストの前に本の題名が付加されている。非表示にされたリンクテキストでは、何のHTMLファイルであるのか、何のPDFファイルであるのかを示している。

コード例:


<?xml version="1.0" encoding="UTF-8"?>
<!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" xml:lang="en" lang="en"> 
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=UTF-8" /> 
<link href="access.css" rel="stylesheet" type="text/css" />
<title>Hidden Link Text </title>
</head>
<body>
<dl>
<dt>Winnie the Pooh </dt>
   <dd><a href="winnie_the_pooh.html">
      <span>Winnie the Pooh </span>HTML</a></dd>
   <dd><a href="winnie_the_pooh.pdf">
         <span>Winnie the Pooh </span>PDF</a></dd>
<dt>War and Peace</dt>
    <dd><a href="war_and_peace.html">
      <span>War and Peace </span>HTML</a></dd> 
    <dd><a href="war_and_peace.pdf">
      <span>War and Peace </span>PDF</a></dd>
</dl>
</body>
</html>

参考リソース

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

検証

手順

この達成方法を使用している各 a 要素に対して:

説明を付加するテキストを提供する要素のスタイルが、1 ピクセル四方の中に収められ、かつ「overflow: hidden;」の状態で表示領域の外側に配置されるように定義されていることを確認する。
そのスタイルが定義されている要素が a 要素の中に含まれていることを確認する。
a 要素の中のコンテンツを組み合わせると、何へのリンクであるかの説明になっていることを確認する。

期待される結果

上記全ての結果が真である。

C8: 単語内の文字間隔を制御するために、CSS の letter-spacing を使用する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.2 (意味のある順序)
- クイックリファレンス 1.3.2 (意味のある順序)
- 達成基準 1.3.2 (意味のある順序)を理解する
注記: この達成方法は、達成基準 1.3.2 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.3.2 を理解するを参照すること。
達成基準 1.4.5 (文字画像)
- クイックリファレンス 1.4.5 (文字画像)
- 達成基準 1.4.5 (文字画像)を理解する
達成基準 1.4.9 (文字画像 (例外なし) )
- クイックリファレンス 1.4.9 (文字画像 (例外なし) )
- 達成基準 1.4.9 (文字画像 (例外なし) )を理解する

解説

この達成方法の目的は、意味の伝わるテキストの流れを維持しながら、スタイルシートによって表示上の文字間隔を調整する方法を示すことである。文字間隔の量を調整するには、CSS の letter-spacing プロパティを使用する。単語の途中に空白文字を入れると意味や発音のされ方が変わってしまうため、間隔の調整はこの方法で行うことが推奨されている。

事例

事例 1: 単語内の文字間隔を広くする

以下の CSS は、レベル 2 の見出しに含まれる各文字に対して 1 文字分に相当する間隔を加える:

コード例:

h2 {	letter-spacing: 1em; }

マークアップは以下の通り:

コード例:


<h2>Museum</h2>

表示結果は、およそ以下のようになる:

コード例:


M u s e u m

参考リソース

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

CSS 2: Letter and word spacing

訳注: 「CSS 2: Letter and word spacing」は、CSS Text Module Level 3§8. Spacing で再定義されている。

検証

手順

文字間に標準以外の間隔があるように見える各単語に対して:

間隔を制御するために CSS letter-spacing プロパティが用いられたかどうかを確認する。

期待される結果

1. の結果が真である。

C9: 装飾目的の画像を付加するために、CSS を使用する

適用 (対象)

画像を表示させるために CSS が利用可能なウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

解説

この達成方法の目的は、単に装飾することだけが目的の画像と、マークアップを追加することなくウェブコンテンツに対して視覚的な整形を行うための画像を追加する方法を示すことである。これによって、支援技術がテキストではないコンテンツを無視することが可能になる。文字サイズの拡大やハイコントラストの設定を妨げている CSS の背景画像を消すことができるように、一部のユーザエージェントでは、利用者の要求に応じて CSS を無視または無効にすることができる。

背景画像は、以下の CSS プロパティで表示させることができる:

background,
background-image,
content (:before 又は :after 疑似要素と組み合わせて使用)
list-style-image.

注: この達成方法は、情報を伝えている画像、なんらかの機能を持っているような画像、主として知覚的なエクスペリエンスを作り出すことを目的としているような画像に対しては使用すべきではない。

訳注: MDN の疑似要素 (Pseudo-elements) に示されているように、:after 及び :after 疑似要素について、コロンを 1 個のみ用いるのは古い、互換性のための構文である。コロンを 2 個置くのが現在の正式な構文であることに注意されたい。

事例

事例 1: HTML ページの背景画像

以下のスタイルシートは、ページ全体の背景画像を指定している。

コード例:

…
<style type="text/css">
body { background: #ffe url('/images/home-bg.jpg') repeat; }
</style>
</head>
<body>
…

事例 2: CSS によるロールオーバーの背景画像

以下のスタイルシートは、利用者がマウスポインタをリンクの上に置いたときの装飾的なロールオーバー効果を出すために CSS の background プロパティを使用している。

コード例:

a:hover { background: #ffe url('/images/hover.gif') repeat; color: #000;
   text-decoration: none;
}

事例 3: タブなどの要素の角を丸くするために使われる CSS による背景画像

以下のスタイルシートでは、要素の角を丸くするために、CSS の background プロパティを使用している。

コード例:

…
  <style type="text/css">
    div#theComments { width:600px; }
    div.aComment { background: url('images/middle.gif') repeat-y left top; 
    margin:0 0 30px 0; }
    div.aComment blockquote { background: url('images/top.gif') no-repeat left top; 
    margin:0; padding:8px 16px; }
    div.aComment div.submitter { background:#fff url('images/bottom.gif') no-repeat left top; 
    margin:0; padding-top:30px; }
  </style>
</head>
<body>
  <div id="theComments">
    <div class="aComment">
      <blockquote>
        <p>Hi John, I really like this technique and I'm gonna use it on my own Website!</p>
      </blockquote>
      <div class="submitter">
        <cite><a href="http://example.com/">anonymous coward</a> from Elbonia</cite>
      </div>
    </div>
    <div class="aComment">
…
 </div>
</div>
…

参考リソース

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

The background property in the CSS 2 specification
HTML 4.01 specification には、body 要素の background 属性は非推奨であると記述されている。

訳注 1: 「background property」は、CSS Backgrounds and Borders Module Level 3§3.10. Backgrounds Shorthand: the background property で再定義されている。この仕様は W3C 勧告ではないが、CSS Snapshot 2018 によれば、今日の CSS を構成する仕様として位置づけられている。

訳注 2: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。HTML5 において、body 要素の background 属性は、は HTML 5.2§11.2. Non-conforming features で不適合な機能として定義されている。

検証

手順

装飾目的の画像の存在を確認する。
それらが CSS に含まれていることを確認する。

期待される結果

1. の結果が真である場合に、2. の結果が真である。

C12: フォントサイズにパーセントを使用する

適用 (対象)

CSS

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.4 (テキストのサイズ変更)
- クイックリファレンス 1.4.4 (テキストのサイズ変更)
- 達成基準 1.4.4 (テキストのサイズ変更)を理解する
注記: この達成方法は、達成基準 1.4.4 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.4.4 を理解するを参照すること。
達成基準 1.4.5 (文字画像)
- クイックリファレンス 1.4.5 (文字画像)
- 達成基準 1.4.5 (文字画像)を理解する
達成基準 1.4.8 (視覚的提示)
- クイックリファレンス 1.4.8 (視覚的提示)
- 達成基準 1.4.8 (視覚的提示)を理解する
注記: この達成方法は、達成基準 1.4.8 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.4.8 を理解するを参照すること。
達成基準 1.4.9 (文字画像 (例外なし) )
- クイックリファレンス 1.4.9 (文字画像 (例外なし) )
- 達成基準 1.4.9 (文字画像 (例外なし) )を理解する

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

C12 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、ユーザエージェントがコンテンツを効果的に拡大縮小できるように、比率にもとづく単位でテキストのフォントサイズを指定することである。body 要素に対してフォントサイズを指定した場合、より個別的なセレクタで上書きされない限り、他の全ての要素に値が継承される。

事例

事例 1: CSS でのパーセントによるフォントサイズ指定

この事例では、どのような場合でも、strong 要素のテキストが周りのテキストよりも常に大きく表示されるように指定してある。そのため、親要素である見出しやパラグラフにフォントサイズが指定されていても、strong 要素でマークアップされた強調語は、周りのテキストよりも大きく表示される。

コード例:


strong {font-size: 120%}

...

<h1>Letting the <strong>user</strong> control text size</h1>
<p>Since only the user can know what size text works for him, 
it is <strong>very</strong> important to let him configure the text size.  
…

参考リソース

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

訳注: フォントに関する CSS の仕様は、CSS Fonts Module Level 3 を参照のこと。この仕様が、CSS 2 のフォントに関する記述に取って代わることに注意されたい。CSS Snapshot 2018 も参照のこと。

検証

手順

フォントサイズを定義する CSS プロパティの値がパーセントであることを確認する。

期待される結果

1. の結果が真である。

C13: 名前付きフォントサイズを使用する

適用 (対象)

CSS

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.4 (テキストのサイズ変更)
- クイックリファレンス 1.4.4 (テキストのサイズ変更)
- 達成基準 1.4.4 (テキストのサイズ変更)を理解する
注記: この達成方法は、達成基準 1.4.4 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.4.4 を理解するを参照すること。
達成基準 1.4.5 (文字画像)
- クイックリファレンス 1.4.5 (文字画像)
- 達成基準 1.4.5 (文字画像)を理解する
達成基準 1.4.8 (視覚的提示)
- クイックリファレンス 1.4.8 (視覚的提示)
- 達成基準 1.4.8 (視覚的提示)を理解する
注記: この達成方法は、達成基準 1.4.8 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.4.8 を理解するを参照すること。
達成基準 1.4.9 (文字画像 (例外なし) )
- クイックリファレンス 1.4.9 (文字画像 (例外なし) )
- 達成基準 1.4.9 (文字画像 (例外なし) )を理解する

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

C13 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、設定したい相対的なフォントサイズを表現するキーワードでフォントサイズを指定することである。これらの値は、ユーザエージェントが継承されたフォントサイズに相対的なフォントサイズを選択できるようにヒントを提供する。

事例

事例 1: CSS でのキーワードによるフォントサイズ指定

この事例では、どのような設定であっても、strong 要素のテキストが周りのテキストよりも常に大きく表示されるように、「larger」というフォントサイズが指定してある。親要素である見出しやパラグラフにフォントサイズが指定されていても、strong 要素でマークアップされた強調語は、周りのテキストよりも大きく表示されるだろう。

コード例:


strong {font-size: larger}

...

<h1>Letting the <strong>user</strong> control text size</h1>
<p>Since only the user can know what size text works for him, 
it is <strong>very</strong> important to let him configure the text size.  
…

参考リソース

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

検証

手順

フォントサイズを定義する CSS プロパティの値が、xx-small、x-small、small、medium、large、x-large、xx-large、smaller、larger の中のどれか一つであることを確認する。

期待される結果

1. の結果が真である。

C14: フォントサイズに em 単位を使用する

適用 (対象)

CSS

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.4 (テキストのサイズ変更)
- クイックリファレンス 1.4.4 (テキストのサイズ変更)
- 達成基準 1.4.4 (テキストのサイズ変更)を理解する
注記: この達成方法は、達成基準 1.4.4 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.4.4 を理解するを参照すること。
達成基準 1.4.5 (文字画像)
- クイックリファレンス 1.4.5 (文字画像)
- 達成基準 1.4.5 (文字画像)を理解する
達成基準 1.4.8 (視覚的提示)
- クイックリファレンス 1.4.8 (視覚的提示)
- 達成基準 1.4.8 (視覚的提示)を理解する
注記: この達成方法は、達成基準 1.4.8 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.4.8 を理解するを参照すること。
達成基準 1.4.9 (文字画像 (例外なし) )
- クイックリファレンス 1.4.9 (文字画像 (例外なし) )
- 達成基準 1.4.9 (文字画像 (例外なし) )を理解する

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

C14 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、ユーザエージェントがコンテンツを効果的に拡大縮小できるように、em 単位でテキストのフォントサイズを指定することである。em はフォントのプロパティなので、フォントのサイズが変わると拡大縮小される。body 要素に対してフォントサイズを指定した場合、より個別的なセレクタで上書きされない限り、他の全ての要素に値が継承される。

事例

事例 1: CSS での em によるフォントサイズ指定

この事例では、どのような場合でも、strong 要素のテキストが周りのテキストよりも常に大きく表示されるように指定してある。そのため、親要素である見出しやパラグラフにフォントサイズが指定されていても、strong 要素でマークアップされた強調語は、周りのテキストよりも大きく表示される。

コード例:


strong {font-size: 1.6em}

...

<h1>Letting the <strong>user</strong> control text size</h1>
<p>Since only the user can know what size text works for him, 
it is <strong>very</strong> important to let him configure the text size.  </p>
…

参考リソース

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

検証

手順

フォントサイズを定義する CSS プロパティの値が em 単位である。

期待される結果

1. の結果が真である。

C15: ユーザインタフェースコンポーネントがフォーカスを受けとったときの提示を変更するために、CSS を使用する

適用 (対象)

CSS、HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

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

C15 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、インタラクティブな要素がフォーカスされたとき、又は利用者がポインティングデバイスを使ってカーソルを上にのせたときに、スタイルシートを使って視覚的なフィードバックを返すようにすることで視覚表現がどれだけ強調されるのかを示すことである。フォーカスされた要素又はカーソルが上にのせられた要素をハイライトすることで、その要素がインタラクティブであること、又はインタラクティブな要素の範囲内であるなどの情報を提供することができる。

複数のモードに対して視覚的なフィードバックを返すことが可能な場合もある。通常、それは要素の上にカーソルをのせるためにマウスを使ったり、又は要素にタブで移動するためのキーボードを使ったりする場合である。

事例

事例 1: リンク要素

この事例では、マウスやキーボードによってフォーカスされたことを示すスタイルが、リンク部分の要素に適用される。リンク部分の要素がフォーカスを受け取ったときに背景色を適用するために、CSS が使用されている。

表示されるコンテンツは次の通り:

コード例:


<ul id="mainnav">
  <li class="page_item">Home</li>
  <li class="page_item"><a href="/services">Services</a></li>
  <li class="page_item"><a href="/projects">Projects</a></li>
  <li class="page_item"><a href="/demos">Demos</a></li>
  <li class="page_item"><a href="/about-us">About us</a></li>
  <li class="page_item"><a href="/contact-us">Contact us</a></li>
  <li class="page_item"><a href="/links">Links</a></li>
</ul>

マウス又はキーボードでフォーカスを受け取ったときに、上記要素の背景色を変更するCSSは次の通り:

コード例:


#mainnav a:hover, #mainnav a:active, #mainnav a:focus {
  background-color: #DCFFFF;
  color:#000066;
}

訳注: WAIC では C15-1 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: C15-1 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例 2: フォーカスを受け取った要素をハイライトする

この事例では、背景色を変更することによって、フォーカスを受け取ったときに入力フィールドのスタイルを変更するために :focus 疑似クラスが使用されている。

コード例:


<html>
  <head>
    <style type="text/css">
      input.text:focus {
        background-color: #7FFF00; 
        color: #000;
      }
      input[type=checkbox]:focus + label, input[type=radio]:focus + label {
        background-color: #FF6; 
        color: #000; 
      }
    </style>
  </head>
  <body>
    <form method="post" action="form.php">
      <p><label for="fname">Name: </label>
        <input class="text" type="text" name="fname" id="fname" />
      </p>
      <p>
        <input type="radio" name="sex" value="male" id="sm" /> <label for="sm">Male</label><br />
        <input type="radio" name="sex" value="female" id="sf" /> <label for="sf">Female</label>
      <p>
    </form>
  </body>
</html>

このコードの使用例: フォーカスを受け取る要素を強調表示する例。

参考リソース

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

訳注: セレクターに関する仕様は、Selectors Level 3 を参照のこと。この仕様が、CSS 2 のセレクターに関する記述に取って代わることに注意されたい。CSS Snapshot 2018 も参照のこと。

検証

手順

フォーカスを得られる各要素に対して:

マウスを使って要素の上にカーソルをのせる。
背景又はボーダーの色が変化することを確認する。
キーボードでフォーカスを与える前に、マウスを動かして対象からカーソルを外す。
キーボードを使って、要素にタブ移動する。
背景又はボーダーの色が変化することを確認する。
その要素がフォーカスを失ったとき、背景又はボーダーの色の変更が除去されることを確認する。

期待される結果

上記、2, 5 及び 6 の結果が真である。

C17: テキストを含むフォーム要素を拡大縮小する

適用 (対象)

(X)HTML, CSS

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.4 (テキストのサイズ変更)
- クイックリファレンス 1.4.4 (テキストのサイズ変更)
- 達成基準 1.4.4 (テキストのサイズ変更)を理解する

解説

この達成方法の目的は、ユーザエージェントによってテキストサイズが変更されたとき、テキストベースのフォームコントロールのサイズ変更を確かにすることである。これは、利用者によって必要とされるサイズでテキストが表示されるため、利用者がテキストを登録し、そして何を入力ボックスに登録したかを読むことができるであろう。

テキストベースのフォームコントロールは、ボタンと同様に入力ボックス (テキスト及びテキストエリア) を含んでいる。

事例

事例 1: コンタクトフォーム

お問い合わせフォームには、いくつかの初歩的な情報があり、利用者が自分の姓と名、電話番号、電子メールアドレスを入力するフォームコントロールがある。すべてのテキスト及びフォームコントロールは、拡大縮小可能な方法で実装されている。これは、Internet Explorer でフォントサイズが継承されていないため、フォームコントロール自体のフォントサイズを指定することも含まれる。

XHTML コンポーネント:

コード例:

<h1>Contact Us</h1>
<p>Please provide us with your details and we will contact you as soon as we can. Note that all of the form fields are required.</p>
<label for="fname">First Name</label><input type="text" name="fname" id="fname" /><br />
<label for="lname">Last Name</label><input type="text" name="lname" id="lname" /><br />
<label for="phone">Telephone</label><input type="text" name="phone" id="phone" /><br />
<label for="email">Email</label><input type="text" name="email" id="email" /><br />
<input type="submit" name="Submit" value="Submit" id="Submit" />

CSS コンポーネント:

コード例:

h1 { font-size: 2em; }
            p, label, input { font-size: 1em; }

このコードの使用例: CSS によって入力のサイズを変更する例。

事例 2: ラジオボタン

この事例は、テキストサイズ機能のある IE で動作する。しかしながら、Firefox 2.0 では拡大縮小されない。

XHTML コンポーネント:

コード例:

<input type="radio" name="r1" value="r1" id="r1" class="geomsize" />
<input type="checkbox" name="c1" id="c1" value="c1" class="geomsize" />

CSS コンポーネント:

コード例:

input.geomsize {
width: 1.2em;
height: 1.2em;}

このコードの使用例: CSS によってラジオボタンとチェックボックスのサイズを変更する例。

検証

手順

利用者が入力したテキストを受け取るテキストベースのフォームコントロールにテキストを入力する。
コンテンツのテキストサイズを 200 ％まで増加させる。
テキストベースのフォームコントロールのテキストが 200 ％まで増加していることを確認する。

期待される結果

3. の結果が真である。

C18: レイアウトデザインのためのスペーサー画像ではなく、CSS のマージンとパディング規則を使用する

適用 (対象)

CSS をサポートするすべての達成方法

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

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

C18 に関するユーザエージェントサポートノートを参照のこと。

解説

ウェブデザイナーは、レイアウト、例えばテーブルまたは段落の字下げをよりよくコントロールするために、しばしばスペーサー画像 (通常は 1 x 1 ピクセルの透過 GIF) を使用する。しかしながら、カスケーディングスタイルシート (CSS) は、スペーサー画像を置き換えることで、レイアウトを十分によりよくコントロールすることができる。マージンとパディングの CSS プロパティは、レイアウトを制御するために単独または組み合わせて使用できる。マージンプロパティ (「margin-top」、「margin-right」, 「margin-bottom」、「margin-left」とショートハンドの「margin」) は、ブロックとして表示される任意の要素に使用でき、要素の外側にスペースを追加する。パディングプロパティ (「padding-top」、「padding-right」、「padding-bottom」、「padding-left」とショートハンドの「padding」) は、任意の要素に使用でき、要素の内側にスペースを追加する。

事例

事例 1

次の例は、二つの部品で構成されている。テーブルの全ての面にマージンとテーブルセルにパディングを指定している CSS コードと、スペース画像を含まず、他のテーブル内にネストされていないテーブルの HTML コード。

コード例:


              
              table { margin: .5em; border-collapse: collapse; } 
              td, th { padding: .4em; border: 1px solid #000; }
            
            ...
            
              <table summary="Titles, authors and publication dates of books in Web development category">
                <caption>Books in the category 'Web development'</caption>
                <thead>
                  <tr>
                    <th>Title</th>
                    <th>Author</th>
                    <th>Date</th>
                  </tr>
                </thead>
                <tbody>
                  <tr>
                    <td>How to Think Straight About Web Standards</td>
                    <td>Andrew Stanovich</td>
                    <td>1 April 2007</td>
                  </tr>
                </tbody>
              </table>

参考リソース

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

訳注: padding 及び margin 関連プロパティは、CSS Box Model Module Level 3 で再定義されている。

検証

この達成方法に利用可能な検証はない。

C19: CSS でテキストの配置を左寄せ又は右寄せに指定する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.8 (視覚的提示)
- クイックリファレンス 1.4.8 (視覚的提示)
- 達成基準 1.4.8 (視覚的提示)を理解する

解説

この達成方法は、CSS の text-align プロパティを使って、テキストのブロックを左または右に揃える方法を説明している。

事例

事例 1

以下の例では、テキストは左揃えになっている。スタイルシートでクラスを定義する:

コード例:

p.left {text-align: left}

コンテンツで、そのクラスを呼び出す。

コード例:

<p class="left"> Lorem ipsum dolor sit …</p>

事例 2

以下の例では、テキストは右揃えになっている。

コード例:

p.right {text-align: right}

コンテンツで、そのクラスを呼び出す。

コード例:

<p class="right"> Lorem ipsum dolor sit …</p>

検証

手順

テキストが、左揃え又は右揃えのいずれかになっていることを確認する。

期待される結果

1.の結果が真である。

C20: ブラウザがサイズ変更されるときに、行が平均で 80 字以下になるようなカラムの幅を設定するために、相対長さを使用する

適用 (対象)

CSS

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、1 行が平均 80 字 (日本語なら 40 字) 以下になるようにして利用者がコンテンツを見ることができるように、CSS で指定することである。こうすることで、テキストの長い行を読む際に、現在読んでいる位置を維持することが困難な読字障害や視覚障害のある利用者が、より効率よくコンテンツをを閲覧したり操作したりできるようになる。この達成方法はまた、文字サイズの拡大に合わせてカラム幅を広くすることにもなり、それによって、文字サイズが大きくなるに従ってテキストの一部が欠けて読めなくなるような事態も発生しにくくなる。

この達成方法は、コンテンツ制作者に対して、CSS を使ってデフォルトでテキストの各行の幅を 80 字 (日本語は 40 字) 以下に制限することを要求するものではない、という点に注意してほしい。それよりもむしろ、CSS レイアウトに相対サイズを用いることを推奨して、利用者が 1 行 80 字以下で読むことができないようなカラム幅には、設定しないようにする。

事例

事例 1

この例では、div 要素の幅はスタイルシートで em 単位で指定されている。

注記: CSS プロパティの max-width は、Internet Explorer 6 以前のバージョンではサポートされていない。

コード例:

#main_content {max-width: 70em}

テキストのブロックは、コンテンツ内の div 要素の中に収められる。

コード例:

<div id="main_content"> 
  <p>Lorem ipsum dolor sit amet, consectetur adipisicing ...</p>
</div>

事例 2

この例では、div 要素の幅はスタイルシートでパーセントで指定されている。

コード例:

#main_content {width: 90%}

テキストのブロックは、コンテンツ内の div 要素の中に収められる。

コード例:

<div id="main_content"> 
  <p>Lorem ipsum dolor sit amet, consectetur adipisicing ...</p>
</div>

参考リソース

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

訳注: CSS2 の「Box Model」は、CSS Box Model Module Level 3 で再定義されている。

検証

手順

カラム幅が、相対的な単位で定義されているかどうかの検査をする。
行の長さが、ブラウザのウィンドウをリサイズしても 80 字 (日本語は 40 字) 以下を維持していることを確認する。

期待される結果

1. 及び 2. の結果が真である。

C21: 行送り幅を CSS で指定する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.8 (視覚的提示)
- クイックリファレンス 1.4.8 (視覚的提示)
- 達成基準 1.4.8 (視覚的提示)を理解する

解説

認知障害を持つ人の多くは、行間なしのテキストのブロックの中で各行を目で追っていくことに困難を覚える。行の高さが文字サイズの 1.5～2 倍程度あると、前の行を読み終えて次の行へより簡単に読み進めていけるようになる。

事例

事例 1

要素の行の高さを 1.5 に設定。スタイルシートで要素の特性を設定している。

コード例:

p { line-height: 150%; }

コンテンツ側では、その要素はドキュメント全体を通して行の高さが 1.5 になる。

コード例:

<p> Lorem ipsum dolor sit …  </p>

事例 2

クラスを指定した要素の行の高さを1.5 (行送り1.5文字) に設定。スタイルシートでクラスの表示を定義。

コード例:

p.tall {line-height:150%}

コンテンツ側では、以下のようにクラスを指定している。

コード例:

<p class="tall"> Lorem ipsum dolor sit …  </p>

事例 3

行間を1行分空けるクラスを設定する。スタイルシートでクラスの表示を定義。

コード例:

p.tall {line-height:200%}

コンテンツ側では、以下のようにクラスを指定している。

コード例:

<p class="tall"> Lorem ipsum dolor sit …  </p>

検証

手順

ブラウザでコンテンツを開く。
テキストのブロック内の行送りが 1.5 と 2 の間であることを確認する。

期待される結果

2.の結果が真である。

C22: テキストの視覚的提示を制御するために、CSS を使用する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、CSS を使ってテキストの視覚的な提示を制御する方法を実践することである。これにより利用者が要求を満たすたように、ユーザエージェントを通してテキストの視覚的な特徴を変更できるようになる。テキストの特徴にはサイズ、色、書体、相対配置などの外観を含んでいる。

CSS は主に提示からドキュメント構造を分離することによってアクセシビリティに有益さを与える。スタイルシートは、マークアップの外部から字間、文字配列、ページにおけるオブジェクトの配置、音声やスピーチのアウトプット、フォントなどの正確な制御ができるように設計されている。マークアップからスタイルを分離することにより、コンテンツ制作者はコンテンツの中でマークアップを単純化し、整理することができ、同時によりアクセシブルにすることができる。

画像内にあるテキストはいくつかのアクセシビリティ上の問題があり、以下のことができない:

ブラウザの設定に応じて大きさを調整する
ブラウザの設定、又は利用者定義のスタイルシートのルールによって指定された色で表示する
ハイコントラストといった、オペレーティングシステムの設定を反映させる

適切な視覚的表現を作り出すためには、これらの要素のテキスト部分には、テキストを使い、セマンティックマークアップとスタイルシートの組み合わせを用いるとよい。このことが効果的に作用するために、利用者のシステム上で利用できると思われるフォントを選び、定義された最初のフォントを持たない利用者のために代替フォントを定義する。最新のマシンとユーザエージェントはしばしばすべてのテキストにスムーズもしくはアンチエイリアスをかけている。そのため見出しやボタンは文字画像に頼ることなくこれらのシステム上できれいに表示される。

次の CSS のプロパティは、テキストのスタイルを指定し、画像のテキストを使う必要性を回避するのに有効である:

font-family プロパティを使って、文字の外観を等幅フォントで表示する。
text-align プロパティを使って、表示域の右側にテキストを表示する。
font-size プロパティを使って、テキストをより大きいサイズで表示する。
font-style プロパティを使って、テキストをイタリック体で表示する。
font-weight プロパティを使って、テキストの文字をどのくらい太く又は細く表示すべきか設定する。
color プロパティを使って、テキストやテキストコンテナに色を表示する。
line-height プロパティを使って、テキストのブロックに対してラインの高さを指定する。
text-transform プロパティを使って、テキストの文字 (大文字小文字の区別) を制御する。
letter-spacing プロパティを使って、テキストの文字間隔を制御する。
background-image プロパティを使って、非テキストの背景上にテキストを表示させることができる。
first-line 疑似クラスを使って、テキストのブロックにおける最初の行の提示を修正することができる。
:first-letter 疑似クラスを使って、テキストのブロックにおける最初の文字の提示を修正することができる。
:before と :after 疑似クラスを使って、テキストのブロックの前後に装飾的な非テキストコンテンツを挿入することができる。

訳注 1: first-line 疑似クラス、:first-letter 疑似クラス、:before 疑似クラス、:after 疑似クラスが挙げられているが、これらは全て疑似要素であり、原文の誤りである。

訳注 2: MDN の疑似要素 (Pseudo-elements) に示されているように、例えば :after 疑似要素について、コロンを 1 個のみ用いるのは古い、互換性のための構文である。コロンを 2 個置くのが現在の正式な構文であることに注意されたい。

事例

事例 1: フォントファミリーを制御するために CSS の font-family を使用する。

XHTML:

コード例:


<p>The Javascript method to convert a string to uppercase is <code>toUpperCase()</code>.</p>

CSS:

コード例:

code { font-family:"Courier New", Courier, monospace }

事例 2: テキストの配置 (配列) を制御するために CSS の text-align を使用する。

XHTML:

コード例:


<p class="right">This text should be to the right of the viewport.</p>

CSS:

コード例:

.right { text-align: right; }

事例 3: テキストのサイズを制御するために CSS の font-size を使用する。

XHTML:

コード例:


<p>09 <strong class="largersize">March</strong> 2008</p>

CSS:

コード例:

strong.largersize { font-size: 1.5em; }

訳注: MDN の strong 要素で示されているように、現在の HTML では strong を重要性を表すものと定義している。

事例 4: テキストの色を制御するために CSS の color を使用する。

注記: この例で用いているスタイルは、情報や構造又は関係性を伝えるためのものではない。

XHTML:

コード例:


<p>09 <em class="highlight">March</em> 2008</p>

CSS:

コード例:

.highlight{ color: red; }

事例 5: イタリック体のテキストにするために CSS の font-style を使用する。

注記: この例で用いているスタイルは、情報や構造又は関係性を伝えるためのものではない。

XHTML:

コード例:


<p>The article is available in the <a href="http://www.example.com" class="featuredsite">Endocrinology 
Blog</a>.</p>

CSS:

コード例:

.featuredsite{ font-style:italic; }

事例 6: テキストの太さを制御するために CSS の font-weight を使用する。

注記: この例で用いているスタイルは、情報や構造又は関係性を伝えるためのものではない。

XHTML:

コード例:


<p>This deal is available <span class="highlight">now!</span></p>

CSS:

コード例:

.highlight { font-weight:bold; color:#990000; }

事例 7: テキストの大文字小文字の区別を制御するために CSS の text-transform を使用する。

注記: この例で用いているスタイルは、情報や構造又は関係性を伝えるためのものではない。

XHTML:

コード例:


<p>09 <span class="caps">March</span> 2008</p>

CSS:

コード例:

.caps { text-transform:uppercase; }

事例 8: テキストの行間を制御するために CSS の line-height を使用する。

CSS の line-height プロパティを使って、段落の行間をフォントの高さの 2 倍に表示する。

XHTML:

コード例:


<p>Concern for man and his fate must always form the<br />  
chief interest of all technical endeavors. <br />
Never forget this in the  midst of your diagrams and equations. </p>

CSS:

コード例:

p { line-height:2em; }

CSS の line-height プロパティを使って、テキストの行間をフォントの高さより少なく表示させる。テキストの 2 行目は、テキストの 1 行目の後に配置されて、あたかも 1 行目の一部だがやや下がっているように見える。

XHTML:

コード例:


<h1 class="overlap"><span class="upper">News</span><br />
<span class="byline">today</span></h1>

CSS:

コード例:

.overlap { line-height:0.2em;  }
.upper { text-transform:uppercase; }
.byline { color:red; font-style:italic; font-weight:bold; padding-left:3em; }

事例 9: 文字間を設定するために CSS の letter-spacing を使用する。

訳注: 原文では、一つ目の説明文が二つ目のコードの説明、二つ目の説明文が一つ目のコードの説明と「さかさま」になっているが、翻訳では正しい組み合わせに修正している。

CSS の letter-spacing プロパティは、2 行目のテキストでより近い文字を表示するために使用される。

XHTML:

コード例:


<h1 class="overlap"><span class="upper">News</span><br />
<span class="byline">today</span></h1>

CSS:

コード例:

.overlap { line-height:0.2em;  }
.upper { text-transform:uppercase; }
.byline { color:red; font-style:italic; font-weight:bold; padding-left:3em; letter-spacing:-0.1em; }

CSS の letter-spacing プロパティは、見出しでさらに離れた文字を表示するために使用される。

XHTML の構成:

コード例:


<h1 class="upper2">News</h1>

CSS:

コード例:

.upper2 { text-transform:uppercase; letter-spacing:1em; }

事例 10: テキストと画像をレイヤー化するために CSS の background-image を使用する。

CSS の font-style プロパティを使って、バナーのテキスト要素を表示させ、background-image プロパティを使って、テキストの後ろの画像を表示させる。

XHTML:

コード例:


<div id="banner"><span id="bannerstyle1">Welcome</span> 
<span id="bannerstyle2">to your local city council</span></div>

CSS:

コード例:


#banner { 
  color:white; 
  background-image:url(banner-bg.gif); 
  background-repeat:no-repeat; 
  background-color:#003399; 
  width:29em; 
}

#bannerstyle1 { 
  text-transform:uppercase; 
  font-weight:bold; 
  font-size:2.5em;
}

#bannerstyle2 { 
  font-style:italic; 
  font-weight:bold; 
  letter-spacing:-0.1em;
  font-size:1.5em; 
}

事例 11: テキストの最初の行の提示を制御するために CSS の first-line を使用する。

CSS の :first-line 疑似クラスを使って、最初の行をより大きなサイズで赤色に表示する。

XHTML:

コード例:


<p class="startline">Once upon a time...<br />
...in a land far, far away...  </p>

CSS:

コード例:

.startline:first-line { font-size:2em; color:#990000; }

事例 12: テキストの最初の文字の提示を制御するために CSS の first-letter を使用する。

CSS の :first-letter 疑似クラスを使って、最初の文字をより大きなサイズで赤く、縦位置を中央揃えにして表示する。

XHTML:

コード例:


<p class="startletter">Once upon a time...</p>

CSS:

コード例:

.startletter:first-letter { font-size:2em; color:#990000; vertical-align:middle; }

参考リソース

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

検証

手順

CSS のプロパティを用いてテキストの視覚的提示を制御しているかどうかを確認する。

期待される結果

1. の結果が真である。

C23: メインコンテンツのテキスト及び背景の色を指定せず、バナー、機能及びナビゲーションなどのような補助的なコンテンツのテキスト及び背景の色を CSS で指定する

適用 (対象)

CSS を用いているウェブページ

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.8 (視覚的提示)
- クイックリファレンス 1.4.8 (視覚的提示)
- 達成基準 1.4.8 (視覚的提示)を理解する

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

C23 に関するユーザエージェントサポートノートを参照のこと。

解説

ウェブページの中には、色を用いてコンテンツをグループ分けをしているものもある。この達成方法の目的は、ウェブページの構成やグループ分けを示す視覚的な情報を残しつつも、メインコンテンツ部分においては特定の文字色と背景色の組み合わせを利用者が選択できるようにすることである。利用者がページ上のすべてのテキストの文字色と背景色を上書きした場合、ウェブページの構成とグループ分けに関する情報は失われる可能性があり、そうなるとそのページを利用することも理解することも難しくなる。

コンテンツ制作者がメインコンテンツ部分の文字色と背景色を指定しなければ、ユーザスタイルシートを使うことなしに、ブラウザでそれらの色を変更することが可能になる。主要コンテンツ以外に対して文字色と背景色を指定するということは、ブラウザはそれらの色を変更しないことを意味する。

この達成方法を使うということは、コンテンツ制作者はメインコンテンツの領域に対してデフォルトの文字色と背景色の組み合わせを使うことになる。結果として、配色は利用者の好みの色に設定したユーザエージェントによって全面的に決められる。つまり、利用者のニーズに最も合う色の選択となり、利用者にとって最も読みやすい配色となる。

事例

事例 1

ある HTML のウェブページでは、ナビゲーションバー、メニューバー及び目次のような主要ではないコンテンツに対して、テキストと背景の色を指定するために CSS を使用している。しかし、メインコンテンツ部分に対しては、テキストにも背景にも色は指定していない。利用者は、自分に合った色とコントラストでメインコンテンツを閲覧するために、ブラウザで自分好みの色を設定する。ページの個々のセクションは、それでもなお視覚的にはっきり区別できる。

事例 2

ある音楽雑誌のサイトには、白い背景に青い文字の記事がある。そのサイトのページの先頭近くでは、そのページに対して異なるスタイルシートを割り当てるリンクを提供している。新しいスタイルシートでは、テキストや背景に対しては色を指定していない。

参考リソース

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

BBC's Web page with instructions how to change the browser colors in most browsers

検証

手順

ブラウザの設定でテキスト、リンク及び背景の色を変更し、デフォルトの色と異なる、補助的なコンテンツに指定されている色とも異なるようする。
注記: ブラウザがそのページに指定されている色を無視するような設定にはしないこと。
メインコンテンツが新しいテキスト、リンク及び背景の色を使用していることを確認する。
補助的なコンテンツのテキスト、リンク及び背景の色が変わらないことを確認する。

期待される結果

2. 及び 3. の結果が真である。

C24: コンテナのサイズに CSS のパーセント値を使用する

適用 (対象)

CSS を用いているウェブページ

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.8 (視覚的提示)
- クイックリファレンス 1.4.8 (視覚的提示)
- 達成基準 1.4.8 (視覚的提示)を理解する
注記: この達成方法は、達成基準 1.4.8 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.4.8 を理解するを参照すること。

解説

この達成方法の目的は、テキストを読むためにはテキストサイズ大きくする必要がある利用者が、1 行のテキストを横スクロールなしで読めるようにすることである。この達成方法を用いるには、コンテンツ制作者はテキストコンテナの幅をパーセント値で指定する。

事例

事例 1

ある新聞サイトでは、画面の中央にコンテンツを表示させている。コンテンツのコンテナ幅は、ページ全体に対するパーセンテージで指定しているため、ロービジョンの人がフォントサイズを大きくしたときも、ブラウザ画面のサイズにあわせてテキストが折り返しされ、横スクロールバーは表示されない。

C20: ブラウザがサイズ変更されるときに、行が平均で 80 字以下になるようなカラムの幅を設定するために、相対長さを使用する

検証

手順

全てのコンテナ幅をパーセント値で指定していることを確認する。
テキストサイズを 200% に増やす。
どの行のテキストを読むにも、横スクロールの必要がないことを確認する。
全てのテキストが、ページ上に見えたままであることを確認する。

期待される結果

1.、3. 及び 4. の結果が真である。

C25: テキスト及び背景の色は指定せずに、ウェブページの各領域の範囲を明確にするためのボーダーやレイアウトを CSS で指定する

適用 (対象)

CSS を用いているウェブページ

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.8 (視覚的提示)
- クイックリファレンス 1.4.8 (視覚的提示)
- 達成基準 1.4.8 (視覚的提示)を理解する

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

C25 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法が意図するのは、ボーダー (境界) やレイアウトは CSS を用いて指定するが、文字色と背景色については利用者のブラウザや OS の設定に従って表示できるように指定しないでおく、ということである。これによって利用者は、自分が見たい色でテキストを見ることができるようになり、同時に、テキストの段組、セクションの周りのボーダー、又はメニューとメインコンテンツの領域を区切る縦線といったレイアウトやページデザインの外観は保つことができるようになる。また、ページに JavaScript のポップアップボックス又はドロップダウンメニューが含まれている場合に色が上書きされるという、一部のブラウザで起こる表示の問題も回避することができる。

ボーダーやレイアウトを示す表示は、文字色と背景色に関する柔軟性と同様に、認知障害のある多くの人にとって役に立つ。しかし、状況によってはこれら二つのニーズは相容れないこともある。それは、利用者がブラウザ上でコンテンツ制作者が選択した文字色と背景色を上書きする必要があるとき、ブラウザがボーダーやレイアウトまでも取り除いてしまうような場合である。これは、ページがシングルカラムでひとつのブロックが他のブロックの下に表示されることを意味し、そうなると、不必要な余白ができ、テキストの 1 行の長さが長くなってしまう。また、ポップアップボックスの背景が透過して、ページ上のテキストの上にボックスのテキストが重なってしまったり、ドロップダウンメニューが透過するかダークグレーの背景になってしまったりすることを意味する。コンテンツ制作者が文字色と背景色を一切指定せず、その一方でボーダーの色やレイアウトを指定した場合、一般的なブラウザのほとんどでは、(コンテンツ制作者が指定した) CSS の他の宣言に影響を与えずにテキストと背景の色を変更することができる。

事例

事例 1

あるウェブページは、HTML を使ってデザインされている。ページを構成する各領域を囲うボーダーの色を指定し、メニューがメインコンテンツ領域の左側にフロートするレイアウトにするために CSS が使用されている。文字色も背景色も指定されていない。利用者がブラウザで自分の色を設定すると、レイアウトを崩すことなしに、利用者に適した色とコントラストでページを閲覧できる。

検証

手順

HTML コンテンツの色を変更できるブラウザでウェブページを開く。
ブラウザの設定で、テキスト、リンク及び背景の色を変更し、ブラウザで現在の設定とは異なる色に変える。
注記: 「ページで指定されている色を無視する」というようなオプションを選択していないことを確認する。
ページに戻り、ページが新しいテキスト、リンク及び背景の色で表示されていることを確認する。
どのボーダーも消えずに表示されており、レイアウトも崩れていないことを確認する。

期待される結果

3. 及び 4. の結果が真である。

C27: DOM の順序を表示順序と一致させる

適用 (対象)

HTML 及び XHTML で使用される CSS

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、ソースコード上のコンテンツの順序が、コンテンツの視覚的提示の順序と同じになるようにすることである。ソースコード上のコンテンツの順序は、コンテンツ制作者によって、CSS による提示結果とは異なるものにされる場合がある。それぞれの順序はその状態では意味の分かるものになっているかもしれないが、支援技術の利用者にとっては混乱をもたらす可能性がある。そのようなことは、(スクリーンリーダーのように) ソースコードに直接アクセスして内容を読み込んでいる場合や、キーボードで操作している場合などに、コンテンツ制作者による提示指定を利用者が無効にすることによって起こり得る。もし、スクリーンリーダーを使ってページの内容をソースの順序で読んでいる全盲の利用者が、ページの内容を表示される順序で読んでいる利用者と一緒に働いていたら、異なる順序の情報に出くわすことで混乱するかもしれない。スクリーンリーダーと組み合わせて画面拡大ソフトウェアを使用しているロービジョンの利用者は、読み上げている箇所を見失って混乱する可能性もある。キーボード利用者は、ソースの順序が表示の順序と違っていると、次のフォーカスの場所が予想と違って困惑することもあるだろう。

表示結果の順序を前提としなければ、ページの全体を理解することが難しい状況もあるかもしれない。その場合、もしソースの順序が異なっていたら、理解することはさらに難しくなってしまう。

ソースの順序が表示結果の順序と同じである場合、すべての人が同じ (正しい) 順序でコンテンツを読んで情報のやり取りをすることができる。

注記: HTML の tabindex 属性には二つの機能がある。ひとつは要素をフォーカス可能にすることであり、もうひとつは要素にフォーカスの順序を割り当てることである。tabindex の値を 0 にするとその要素はフォーカス可能になるが、フォーカスが追加されるだけで順序はソースの通りになる。フォーカスの順序は、tabindex に指定された正の値だけで昇順となる。tabindex の値をドキュメントオブジェクトモデル (DOM) の要素の順序と異なるように設定することは、支援技術の利用者にとっては不適当な順序となることもある。これは主に、tabindex が CSS ではなく、HTML 又は XHTML で指定されていることによるものだ。この点については、将来の仕様で変更される可能性がある。それは、視覚的な提示の順序とは異なる可能性もある。

事例

あるオンライン新聞の表示では、ナビゲーションバーをイニシャルロゴの直下であるページの左上に配置している。ソースコードでも、ナビゲーションの要素はロゴを指定している要素の後になっている。

参考リソース

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

Microsoft Internet Explorer Developer Toolbar を使用すると、Microsoft の Internet Explorer でスクリプトによって生成された DOM のチェックが可能になる。
Firebug を使用すると、Firefox でスクリプトによって生成された DOM のチェックが可能になる。

訳注 1: 「Microsoft Internet Explorer Developer Toolbar」はページが削除されているが、代わりに開発者ツールを使用できる。詳細については、Internet Explorer 開発者ツールを理解するを参照のこと。

訳注 2: Firefox のアドオン「Firebug」は開発が終了している。代わりに開発ツールを使用できる。開発ツール | MDN も参照のこと。

訳注 3: Google Chrome の場合、類似のツールが利用できる。詳細については、Chrome DevTools | Tools for Web Developers | Google Developers を参照のこと。

訳注 4: Edge の場合も、類似のツールが利用できる。詳細については、Microsoft Edge Developer Tools - Microsoft Edge Development | Microsoft Docs を参照のこと。

検証

手順

エンドユーザに提供されているウェブページのコンテンツの順序を視覚的に検査する。
DOM を表示できるツールを使って、DOM 内の要素を検査する。
ソースコードセクション上でのコンテンツの順序が、ウェブページのコンテンツの視覚的提示と一致していることを確認する (例: 英語のページの場合、順序は上から下へ、左から右へとなる)。

期待される結果

3. の結果が真である。

C28: em 単位を用いて、テキストコンテナのサイズを指定する

適用 (対象)

CSS

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.4 (テキストのサイズ変更)
- クイックリファレンス 1.4.4 (テキストのサイズ変更)
- 達成基準 1.4.4 (テキストのサイズ変更)を理解する
注記: この達成方法は、達成基準 1.4.4 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.4.4 を理解するを参照すること。

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

C28 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、テキストを含むボックス又はテキストの入力を受け付けるボックスの幅及び又は高さを、em 単位を用いて指定することである。これによって、文字サイズを変更できるユーザエージェントは、文字サイズの設定の変更に連動させてテキストを含むボックスの大きさも変更できるようになる。

テキストを含むボックスの幅及び又は高さを他の単位を使って指定していると、文字サイズの拡大によってテキストがボックスに入りきらなくなり、その一部が見えなくなってしまう危険性がある。

大枠のボックス (コンテナ) は、一般にウェブページ内のテキストの配置をコントロールし、そこにはレイアウトのための要素と構造を示す要素、及びフォームのコントロールを含むことができる。

事例

事例 1: テキストを含むレイアウト用のボックスのサイズに em 単位を使う

この事例では、ウェブページのメインコンテンツ領域の左側にナビゲーションメニューを配置するために、id 属性の値として「nav_menu」を指定した div 要素を使用している。ナビゲーションメニューは、id 属性の値として「nav_list」を指定したテキストリンクのリストで構成されている。ナビゲーションのリンクを含むコンテナの幅は em 単位で指定されている。

コード例:

#nav_menu { width: 20em; height: 100em }

#nav_list { font-size: 100%; }

事例 2: テキストベースのフォームのコントロールに em 単位を使う

この事例では、テキストを含む、又は利用者によるテキスト入力を受け付ける input 要素に「form1」というクラス名を指定している。フォントサイズをパーセント単位で、これらの要素の幅を em 単位で定義するために CSS の規則が用いられている。これによって、フォームコントロール内のテキストは、部分的に欠けて見えなくなってしまうことなく文字サイズの変更に合わせてリサイズされるようになる (フォームコントロールの幅自身も文字サイズに合わせてリサイズされるようになるため)。

コード例:

input.form1 { font-size: 100%; width: 15em; }

事例 3: ドロップダウンボックスに em 単位を使う

この事例では、select 要素に「pick」というクラス名を指定している。フォンサイズをパーセント単位で、幅を em 単位で定義するために CSS の規則が使用されている。これによって、フォームコントロール内のテキストは、部分的に欠けて見えなくなってしまうことなく文字サイズの変更に合わせてリサイズされるようになる。

コード例:

select.pick { font-size: 100%; width: 10em; }

事例 4: テキストベースではないフォームのコントロールに em 単位を使う

この事例では、チェックボックス又はラジオボタンの input 要素に「choose」というクラス名を指定している。これらの要素の幅と高さを em 単位で定義するために CSS の規則が使用されている。これによって、フォームコントロールは、文字サイズの変更に合わせてリサイズされるようになる。

コード例:

input.choose { width: 1.2em; height: 1.2em; }

検証

手順

テキストを含む、又はテキストの入力を受け付けるコンテナを特定する。
そのコンテナの幅及び／又は高さが em 単位で指定されていることを確認する。

期待される結果

2. の結果が真である。

C29: 適合している代替版を提供するために、スタイルスイッチャーを使用する

適用 (対象)

クライアントサイド又はサーバーサイドのスクリプトとともに使用される CSS

これは、次の達成基準に関連する達成方法である:

適合要件 1 (適合レベル)

解説

ウェブページのデフォルトの提示が部分的に達成基準を満たさない場合、「適合要件」の条項 (適合要件 1) にある「代替版」を用意することで必要条件を満たすことができる。必要条件によっては、ページのあらゆる側面が主張したレベルに適合するように提示を調整できるリンク又はコントロールによってスタイルスイッチャーを呼び出すことで、コンテンツ制作者が同じ情報の複数バージョンの提供を避けることを可能にする。

この達成方法の目的は、ウェブページの適合している代替版を提供するために、スクリプトと組み合わせて CSS を使う方法を示すことである。この達成方法では、コンテンツの提示を制御するために使用されている CSS を変更するコントロールを提供することで、コンテンツ制作者はコンテンツの代替表示を提供する。ウェブページ内で提供されるコントロールは、そのレベルで要求される達成基準を満たすことができるような提示方法を利用者が選択及び変更することを可能にする。これによって、以下のような状況において、利用者が異なる提示方法を選択できるようになる:

パソコンの知識や権限がないことが原因で、利用者はブラウザや OS の設定を調整できないかもしれない
テキストが、ブラウザや OS の設定では対処できない方法で提供されている (テキストが画像の中に書き込まれているなど)
コンテンツのデフォルトの提示では、一部の利用者に対して十分なコントラストがない

この達成方法で達成させるには、以下の 3 項目を満たしていなければならない。

オリジナルのページのリンク又はコントロール自身は、代替の提示を通して達成基準を満たしていなければならない。例えば、スタイルスイッチャーが大きなフォントサイズを提供するために使用され、かつそのコントロールが小さいフォントを用いて提示される場合、利用者はそのコントロールを作動させてその代替の提示を見ることができないかもしれない。
新しいページは、オリジナルのページと同じすべての情報と機能を含んでいなければならない。
新しいページは、希望する適合レベルのすべての達成基準に適合しなければならない。たとえば、ひとつの要求は満たすが、それを使うと別の要求に適合しなくなってしまうような代替スタイルシートは使用できない。

スタイルスイッチャーを使う場合は、以下の課題と制限について検討することが重要である:

利用者が行うことのできる変更の数や形式は、ウェブページのコンテンツ制作者によって制御される範囲に限定される。できる限り多くの利用者のニーズに対応できるようにするために、さまざまな提示と設定項目が提供されるべきである。しかしながら、コンテンツ制作者は、利用者に多くのオプションを提供することに起因する、利用者にとっての設定可能な項目と複雑さの相互作用について熟考することも重要である。
あるページから別のページに移動しても利用者の設定を保持しておくには、利用者の機器にクッキーで保存したり (詳細はリソースのセクションを参照)、ウェブサーバーに保存されるプロファイルにクエリー文字列として渡して格納するなどの方法で実現できる場合がある。
スタイルスイッチャーを実装するための技術的手法は、利用者の環境においていくつかの技術が利用可能であることを前提としている (たとえば、多くのクライアントサイドソリューションは、JavaScript と CSS の両方が利用可能であることを必要とする)。これらのウェブコンテンツ技術が適合のために当てにできる場合を除き、クライアントサイドのサポートとウェブコンテンツ技術の利用可能性が保証されない場合には、コンテンツ制作者はサーバーサイドのウェブコンテンツ技術を使うことを検討すべきである。その代案としては、これらのウェブコンテンツ技術のサポートを適合のために当てにできない場合に、使用されているいくつかのウェブコンテンツ技術が有効でなくてもコンテンツが確実に適切な表現に変換されるような達成方法を使うことが、より良いページにするための効果的な方法となる。

事例

事例 1: 異なる外部スタイルシートファイルを適用するために JavaScript のコントロールを使う

この例では、文字色と背景色を変更するリンクを JavaScript で提供する。そのリンクは、利用者の環境で JavaScript がサポートされており、かつ有効な場合にのみ挿入されるようにすべきである。これは、そのリンク自身を挿入するためにスクリプトを使う (つまり JavaScript がサポートされており、かつ有効な場合にのみリンクが表示される) ことで実現できる。

以下のコードは、JavaScript に依存した色を変更するリンク並びに、ウェブページのコンテンツの一部、関連するスタイルシート規則、及び色を変更するリンクが選択されたときに使われるスタイルシートを変更する JavaScript を示している。

この例は、現在のページの表示だけに適用される。実稼働環境では、利用者がそのサイトで一度選択すれば済むように、その設定をクッキーまたはサーバーサイドのユーザプロファイルに保存することが望ましい。

XHTML (抜粋):

コード例:


In <head> section:

  <link href="main.css" rel="stylesheet" type="text/css" />
  <link id="currentCSS" href="defaultColors.css" rel="stylesheet" type="text/css" />

In <body> section:

<div id="colorswitch">
<p>Change colors:</p>
  <ul class="inline">
    <li><a href="#" onClick="javascript:changeColors('altColors1.css');return false;" 
      id="altColors1">dark blue on white</a></li>
    <li><a href="#" onClick="javascript:changeColors('altColors2.css');return false;" 
      id="altColors2">yellow on black</a></li>
    <li><a href="#" onClick="javascript:changeColors('altColors3.css');return false;" 
      id="altColors3">black on pale yellow</a></li>
    <li><a href="#" onClick="javascript:changeColors('altColors4.css');return false;" 
      id="altColors4">black on white</a></li>
    <li><a href="#" onClick="javascript:changeColors('defaultColors.css');return false;" 
      id="default">Reset to default</a></li>
  </ul>
</div>
<div id="mainbody">
  <h1>Conference report</h1>
  <p>Last week's conference presented an impressive line-up of speakers...</p>
</div>

CSS (抜粋):

コード例:


In main.css:

body{ font-family: Geneva, Arial, Helvetica, sans-serif; margin: 2em; }

#mainbody { 
    padding: 1em; 
}

#colorswitch {
    float: right; 
    width: 12em; 
    border: 1px #000066 solid; 
    padding:0 1em 1em 1em; margin:0;
}

#colorswitch p { 
    padding-top:.5em; 
    font-weight:bold;
}

In defaultColors.css:

body, p { 
    color:#000000; 
    background-color:#FFFFFF; 
}

h1, h2, h3 {
        color:#990000; 
        background-color:#FFFFFF;
}

In altColors1.css:

body, h1, h2, h3, p, a { 
    color:#000066; 
    background-color:#FFFFFF; 
}

In altColors2.css:

body, h1, h2, h3, p, a { 
    color:#FFFF33; 
       background-color:#000000; 
}

In altColors3.css:

body, h1, h2, h3, p, a { 
    color:#000000; 
    background-color:#FFFF99; 
}

In altColors4.css:

body, h1, h2, h3, p, a { 
    color:#000000; 
    background-color:#FFFFFF; 
}

JavaScript (抜粋):

コード例:

function changeColors (newCSS)
{
  document.getElementById('currentCSS').href = newCSS; 
}

このコードの実装サンプル: 異なる外部スタイルシートファイルを適用するために JavaScript のコントロールを使う

事例 2: CSS プロパティを変更するためにクライアントサイドの JavaScript を使用する

この例はコンテンツの一部分を単純に変更するもので、複雑なサイトやページに対してはあまり実用的なものではないかもしれない。この例では、特定のコンテンツを強調表示するための背景として (あらかじめ用意された選択肢から) 利用者が選択した色を反映させるために、クラス名を変更する目的でクライアントサイドの JavaScript を使用している。

注記: 以下のコードには、達成方法を理解しやすくする目的で、XHTML コード内から JavaScript を呼び出す部分が含まれている。しかし、コンテンツ制作者は、JavaScript を組み込むためのその時点でのベストプラクティスを採用することが推奨される (控えめな JavaScript とプログレッシブエンハンスメントについての詳細はリソースを参照)。

XHTML (抜粋):

コード例:


<h1>Product comparison</h1>
<p>The products you selected to compare are listed below. 
Any differences between the products are highlighted and italicized.</p>
<p class="inlinePara">Change hightlight color: </p>
<ul class="inline">
  <li><a href="#" onClick="changeColor('hghltLightYellow');return false;" 
    class="hghltLightYellow">light yellow</a></li>
  <li><a href="#" onClick="changeColor('hghltBrightYellow');return false;" 
    class="hghltBrightYellow">bright yellow</a></li>
  <li><a href="#" onClick="changeColor('hghltLightBlue');return false;" 
    class="hghltLightBlue">light blue</a></li>
  <li><a href="#" onClick="changeColor('hghltBrightBlue');return false;" 
    class="hghltBrightBlue">bright blue</a></li>
  <li><a href="#" onClick="changeColor('hghltLightRed');return false;" 
    class="hghltLightRed">light red</a></li>
  <li><a href="#" onClick="changeColor('hghltDrkRed');return false;" 
    class="hghltDrkRed">dark red</a></li>
</ul>
<table width="400" border="1">
  <tr>
    <td> </td>
    <th scope="col">Product 1</th>
    <th scope="col">Product 2</th>
  </tr>
  <tr>
    <th scope="row">Aspect 1</th>
    <td>Yes</td>
    <td>Yes</td>
  </tr>
  <tr>
    <th scope="row">Aspect 2</th>
    <td class="hghltLightYellow">Yes</td>
    <td class="hghltLightYellow">No</td>
  </tr>
  <tr>
    <th scope="row">Aspect 3</th>
    <td>Yes</td>
    <td>Yes</td>
  </tr>
</table>

CSS (抜粋):

コード例:

body { color:#000000; background-color:#FFFFFF; }

.hghltLightYellow { color: #000000; background-color: #FFFF99; font-style:oblique; }
.hghltBrightYellow { color: #000000; background-color: #FFFF00; font-style:oblique; }
.hghltLightBlue { color: #000000; background-color: #33FFFF; font-style:oblique; }
.hghltBrightBlue { color: #FFFFFF; background-color: #0000FF; font-style:oblique; }
.hghltLightRed { color: #000000; background-color: #FF6266; font-style:oblique; }
.hghltDrkRed { color: #FFFFFF; background-color: #993300; font-style:oblique; }

.inlinePara {display:inline; }
.inline {display: inline; margin-left:0px; padding-left:0px; line-height:3em; }
.inline li { display:inline; }
.inline li a {padding: 0.5em 1em; border: 2px solid #000000; }

JavaScript (抜粋):

コード例:

function changeColor(hghltColor)
{
  // 表のセルのデータを配列に入れる
 
 var els = document.getElementsByTagName('td');

  // 配列の要素の中から、"hghlt"で始まるクラス名を探す
  // 見つかったら、クラスの値を現在選択されているものに変更する
  // このスクリプトは、td要素のクラスは強調表示のためだけに使用されていることを前提としている点に注意

  for (var i=0; i<els.length; i++)
  {
    if (els[i].className.indexOf("hghlt") == 0) { els[i].className = hghltColor; }
  }
}

このコードの実装サンプル: CSS プロパティを変更するためにクライアント JavaScript を使う

事例 3: 異なる外部スタイルシートファイルを適用するために PHP の $_GET を使う

このシンプルな例では、二つあるうちの一つの外部スタイルシートを割り当てるために PHP の $_GET を使用している。同様のことは、PHP の様々な機能を使って実現できる。この例では、現在のページの表示だけに適用される。実際の制作においては、利用者がそのサイトにおいて一度選択すれば済むように、設定をクッキーまたはサーバーサイドのユーザプロファイルに保存することが望ましい。

以下のコードは PHP であるが、同様のアプローチは様々なサーバーサイドのウェブコンテンツ技術によって可能である。

PHP と XHTML (抜粋):

コード例:


At the beginning of the PHP page:

<?php
$thestyle = $_GET['set'];
if ($thestyle == "style1")
	{
	$thestyle = "style2";
	}
else
	{
	$thestyle = "style1";
	}
?>


In the <head> section:

   <link rel="stylesheet" type="text/css" media="screen" href="<?php echo($thestyle);?>.css" >


In <body> section:

<?php
if ($thestyle == "style1") {
	echo "<a href=\"index.php?set=style1\">Switch to Style Sheet Two</a>";
	}
else {
	echo "<a href=\"index.php?set=style2\">Switch to Style Sheet One</a>";
	}
?>

<div id="mainbody">
  <h1>Conference report</h1>
  <p>Last week's conference presented an impressive line-up of speakers...</p>
</div>

CSS (抜粋):

コード例:


In style1.css:

  body, p { color:#000000; background-color:#FFFFFF; }
  h1, h2, h3 {color:#990000; background-color:#FFFFFF; }

In style2.css:

  body, h1, h2, h3, p, a { color:#FFFF00; background-color:#000000; }

このコードの実装サンプル: 異なる外部スタイルシートファイルを適用するために PHP の $_GET を使う

事例 4: 代替スタイルシートを提供するために JSP を使用する

以下の例では二つのファイルを使用している:

フォームを含む Java Server Page (JSP) 及びフォームの処理コード
上記ページ及び同様のスタイルを使用する他のページで使用される関数を含むインクルードファイル

サーバーサイドのコードは、利用者が選択したスタイルシートのための通常の link 要素及び他のスタイル用の「alternate stylesheet」のついた link 要素を出力する。そのコードは、二つめの例にあるように、クライアントサイドのコードのフォールバックとして使用することもできる。

フォームを含む JSP ページ:

コード例:


 <%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"
 %><%@include file="_jsp/styleswitch.jsp"%><?xml version="1.0" encoding="UTF-8"?>
 <!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="en" xml:lang="en">
 <head>
   <meta content="text/html; charset=utf-8" http-equiv="Content-Type" />
   <title>Change Style</title>
   <%
     String fStyle = "";
     String styleName = "style";
     String defaultStyle = "default";
     Cookie[] cookies = request.getCookies();
 
     // get style from post request parameters
     if (request.getMethod().equals("POST") && request.getParameter("styleSelect") != null) {
       fStyle = request.getParameter("styleSelect");
       // code that validates user input (security) not shown
       
       if (fStyle.equals("nostyle")) { // user prefers no author style
       } else { // user requests author style
         out.println(createStyleLinks(fStyle).toString());
       }
       
       storeStylePreferenceCookie(request, response, fStyle);
     } else if (request.getMethod().equals("GET")) { 
     // GET request; get style from cookie; else default style links
       // get style from cookie
       if (cookies != null) {
         // get style from cookies
         fStyle = getStyleFromCookies(cookies);
 
         if ( !fStyle.equals("NULL_STYLE") ) { // user requests author style
             out.println(createStyleLinks(fStyle).toString());
         } else { // no cookie for style; process request for style preference
           // default style links
           out.println(createStyleLinks(defaultStyle).toString());
         }
       } else { // GET request without cookies: default styles
         out.println(createStyleLinks(defaultStyle).toString());
       }//end else cookies
     }
   %>
 </head>
 <body id="home">
   <form action="_styleSwitch.jsp" method="post" id="styleswitchform" name="styleswitchform">
     <p><label for="styleSelect">Select style: </label>
       <select id="styleSelect" name="styleSelect">
         <option value="default">Default (shades of green)</option>
         <option value="wonb">White on black</option>
         <option value="bonw">Black on white</option>
       </select>
       <input type="submit" value="Change Style" />
     </p>
   </form>
 </body>
 </html>

上記ファイルにインクルードされる「styleswitcher.jsp」ファイル:

コード例:

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
 <%!
   /**
    * Get the links (link elements) to the CSS files based on cookies, ...
   */
   private String getStyleLinks(HttpServletRequest request) {
     String styleLinks = "";
     Cookie[] cookies = request.getCookies();
     String defaultStyle = "default";
     String tempStyle = "";
     // GET request; get style from cookie; else default style links
     // get style from cookie
     if (cookies != null) {
       // get style from cookies
       tempStyle = getStyleFromCookies(cookies);
 
       if ( tempStyle.equals("NULL_STYLE") ) { 
         // no cookie for style; process request for style preference
         // default style links
         styleLinks = createStyleLinks(defaultStyle).toString();
       } else { // user requests author style
         styleLinks = createStyleLinks(tempStyle).toString();
       }
     } else { // GET request without cookies: default styles
       styleLinks = createStyleLinks(defaultStyle).toString();
     }//end else cookies
     
     return styleLinks;
   }
 
   /**
    * Get style cookie from request
   */
   private String getStyleFromCookies( Cookie[] cookies ) {
     String fStyle = "NULL_STYLE";
     for (int i = 0; i < cookies.length; i++) {
       Cookie cookie = cookies[i];
       String name = cookie.getName();
       
       if ( name.equals("style") ) {
         fStyle = cookie.getValue();
         // code that validates cookie value (security) not shown
       }
     }
     return fStyle;
   }
 
   /**
    * Store the style preference in a persistent cookie
   */
   private void storeStylePreferenceCookie(HttpServletRequest request, 
     HttpServletResponse response, String theStyle) {
     final int ONE_YEAR = 60 * 60 * 24 * 365;
     Cookie styleCookie = new Cookie("style", theStyle);
     styleCookie.setMaxAge(ONE_YEAR);
     response.addCookie(styleCookie);
   }
 
   /**
    * Create the link elements for the stylesheets
   */
   private StringBuffer createStyleLinks(String prefStyle) {
     StringBuffer theStyleLinks = new StringBuffer();
     //two-dimensional array with identifiers (adding '.css' gives the name of the CSS file) 
     // and strings for the title attribute of the link element
    // the identifiers must correspond to the in the "value" attributes in the "option"
    // elements in the style switcher form
     String [] [] styles = {
       { "default", "Default style"},
       { "wonb", "White on black"},
       { "bonw", "Black on white"}
     };
 
     // loop over 2dim array: if styles[i][1] matches prefStyle, 
     // output as normal, else as alternate stylesheet
     for (int i = 0; i < styles.length; i++) {
       if ( styles[i][0].equals(prefStyle) ) { // output pref stylesheet as normal stylesheet
         theStyleLinks.append("<link rel=\"stylesheet\" href=\"_css/").append(styles[i][0])
           .append(".css\" title=\"").append(styles[i][1]).append("\" type=\"text/css\" />").append("\n");
       } else { // output other stylesheets as alternate stylesheets
         theStyleLinks.append("<link rel=\"alternate stylesheet\" href=\"_css/")
           .append(styles[i][0]).append(".css\" title=\"").append(styles[i][1])
           .append("\" type=\"text/css\" />").append("\n");
       }
     } // end for loop
 
     return theStyleLinks;
   }
 %>

他の JSP ページは、以下のコード (include / scriptlet) を用いてこのコードを使用できる:

コード例:

<%@include file="_jsp/styleswitch.jsp"%><% out.println(getStyleLinks(request)); %>

参考リソース

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

Build your own PHP style sheet switcher

クッキーを使用する

クッキーを通して利用者のコンピュータ上に情報を保管することによって、利用者による設定はページ全体に渡って永続的に保存しておくことができる。この機能を利用するには、利用者のコンピュータでクッキーがサポートされており、かつその利用が許可されている必要がある。クッキーは、Javascript のようなクライアントサイドのスクリプト、または CGI スクリプトのようなサーバーサイドのスクリプトを使用することで、作成、読み込み、変更、及び削除することができる。クライアントサイドの実装に依存するということは、クッキーがサポートされその利用が許可されていることに加えて、利用者のコンピュータでその達成方法がサポートされており、かつ利用可能であることを要求することになる。

クッキーの生成と使用方法に関する情報はウェブ上にある。以下にいくつかの参考となるページを示す。

コンテンツ制作者はクッキーをサポートしているかどうかのテストを行い、もしサポートされていなければ別のコントロールを提供することが推奨される。この別のコントロールには、「この設定をすべてのページに適用する」のような設定の有効化に関する情報が含まれるべきである。メッセージや別のコントロールの設定に応じて利用者に向けて表示されるページは、クッキーの動作環境とそれ以外の環境で利用できるオプションについての情報を提供する。利用者がクッキーを有効にできない状況において、もし利用者がサイトの閲覧を継続することを選択した場合、それはどうなることを意味するのかということについての説明を含める。そしてクッキーをサポートしている場合と同様の結果を得るにはユーザエージェントをどう設定すればよいかということについての情報を提供する。

例:「このブラウザはクッキーを受け付ける設定になっていません。このサイトでは、サイト内の全ページに渡って、あなたの変更した設定を適用するためにはクッキーが有効になっている必要があります。お使いの環境においてクッキーを有効にする方法については　How to Enable Cookies　を参照してください。ただし、これを実行するためには、お使いのコンピュータにおける管理者の権限が必要となる場合がありますので注意してください。クッキーが利用できない場合、あなたの設定はこのサイト内の他のページも含めて保存されません。弊社では、この機能をコンピュータの性能に関わらず提供できるよう努力しておりますが、それが実現できるまでの間でも、各ページにおいて設定を変更することは可能です。」

プログレッシブエンハンスメントと控えめな JavaScript

HTML 又は XHTML ページにおける JavaScript 実装をするための現在のベストプラクティスは、構造及び提示からコンテンツの動作をある程度分離させて使用することである。「プログレッシブエンハンスメント」及び「控えめな JavaScript」という用語は、ページの機能を向上又改善するが、JavaScript がサポートされていない場合でもコンテンツが機能し続けられるように優雅に変換するスクリプトを表すのによく使用されている。

より詳しく知るための推奨される情報:

検証

手順

利用者が代替となる提示を選択できるようなコントロールがウェブページに含まれていることを確認する。
個々の CSS スタイルのプロパティを変更する、又は代替スタイルシートをアクティブにすることによって、コントロールが提示の変更していることを確認する。
結果として表示されたページは、元のページの適合している代替版であることを確認する。

期待される結果

上記の全ての結果が真である。

C30: テキストを文字画像に置き換えるために CSS を利用し、切り替えのためのユーザインタフェースコントロールを提供する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、利用者が彼らの好みに従ってコンテンツを見ることができるような方法で構造化された HTML テキストを画像化されたテキストに置き換えるための CSS の用い方を実践することである。この達成方法を用いるには、コンテンツ制作者はページの構造をマークアップするためにセマンティックな要素を用いる HTML ページを作ることから始める。次にコンテンツ制作者はページに対して 2 またはそれ以上のスタイルシートを作成する。一つめのスタイルシートは HTML テキストをテキストとして表現し、二つめはいくつかの HTML テキストをテキストの画像に置き換えるために CSS の機能を用いている。最後に、server-side 又は client-side scripting の使用を通して、コンテンツ制作者は利用者が利用するビューを切り替えることができるコントロールを提供する。

この達成方法は、文字画像を含まない表現が利用可能であり、かつ、利用者が代替表現に切り替えることができるユーザインタフェースコントロールが関連する達成基準を満たす限り、達成基準 1.4.5 又は 1.4.9 を満たすために用いることができる。可能であれば、コンテンツ制作者はデフォルトの表現として文字画像を含まない表現を配信すべきである。更に、切り替えのためのコントロールはページの先頭近くに配置されるべきである。

「画像の置き換え」の達成方法は、さまざまなユーザエージェント、構成、及び支援技術の課題との互換性 (詳細は「参照リソース」を参照) に取り組むために多様なものが開発されてきた。コンテンツ制作者がテキストの置き換えのために用いる数々のアプローチがある一方、その達成方法がスクリプト、CSS、画像 (又はそれらの組み合わせ) をオフにした場合に正確に動作するかどうか、支援技術との互換性を考慮することは重要である。すべての場合において動作する単一の解決法を見出すことは難しいので、この達成方法は、利用者が画像置き換えの達成方法を含んでいない表現へ切り替えることのできるコントロールを用いることを推奨している。

注記: この達成方法は、不適合コンテンツのための適合している代替版のページを提示するために、スタイル切り替えの達成方法との組み合わせで用いることができる。更なる情報として C29: 適合している代替版を提供するために、スタイルスイッチャーを使用すると適合している代替版を理解するを参照。

事例

事例 1

デザインスタジオのサイトは、利用者が彼らのウェブページの 2 種類の提示を見ることができるようにスタイルの切り替えを用いている。デフォルトのバージョンでは、見出しのテキストが文字画像で置き換えられている。ページ上のコントロールによって利用者はテキストで見出しを表現したバージョンへ切り替えることができる。

CSS:

コード例:

...
<div id="Header"> 
  <h1><span>Pufferfish Design Studio</span></h1> 
  <h2><span>Surprising Identity and Design Solutions</span></h2> 
  </div> 
...

文字画像を含んだ提示のための CSS を以下に記す。見出し要素のコンテンツを画面の外に配置して非表示にするためにポジショニングを使用することで、テキストはスクリーンリーダー利用者が利用可能な状態に保持されていることに注意。

コード例:

...
#Header h1 {
	background-image: url(pufferfish-logo.png);
	height: 195px;
	width: 290px;
	background-repeat: no-repeat;
	margin-top: 0;
	position: absolute;
	}
#Header h1 span {
	position: absolute;
        left: -999em;
	}
#Header h2 {
	background-image: url(beauty.png);
	background-repeat: no-repeat;
	height: 234px;
	width: 33px;
	margin-left: 8px;
	position: absolute;
	margin-top: 250px;
	}
#Header h2 span {
	position: absolute;
        left: -999em;
	}

文字画像を含まない提示のための CSS。

コード例:

...
#Header h1 {
	font: normal 200%/100% Garamond, "Times New Roman", serif;
	margin-bottom: 0;
	color: #000099;
	background: #ffffff;
	}

#Header h2 {
	font: normal 160%/100% Garamond, "Times New Roman", serif;
	margin-bottom: 0;
	color: #336600;
	background: #ffffff;
	}

参考リソース

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

訳注: Background に関するプロパティは、CSS Backgrounds and Borders Module Level 3 で再定義されている。この仕様は W3C 勧告ではないが、CSS Snapshot 2018 によれば、今日の CSS を構成する仕様として位置づけられている。

検証

手順

ウェブページに利用者が代替となる提示を選択できるコントロールが含まれていることを確認する。
コントロールがアクティブである時、結果のページは文字画像が用いられている箇所全てにおいてテキスト (プログラムによる解釈が可能なテキスト) を含んでいることを確認する。

期待される結果

上記の全ての結果が真である。

4. クライアントサイドスクリプトの達成方法

SCR1: 利用者が初期設定の制限時間を延長できるようにする

適用 (対象)

クライアントサイドスクリプトによりコントロールされた制限時間。

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.1 (タイミング調整可能)
- クイックリファレンス 2.2.1 (タイミング調整可能)
- 達成基準 2.2.1 (タイミング調整可能)を理解する
注記: この達成方法は、達成基準 2.2.1 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 2.2.1 を理解するを参照すること。

解説

この達成方法の目的は、スクリプトがデフォルトの制限時間のある機能を提供する際、その時間を延長するメカニズムを提供することによって、利用者がデフォルトの制限時間を延長できるようにすることである。利用者がより長い制限時間を要求できるようにするために、利用者がより長い制限時間を入力できる、又はより多くの時間を必要としていることを示す (例えば) フォームをスクリプトが提供することができる。制限時間が切れそうであることを利用者に警告する場合 (SCR16: 制限時間が切れようとしていることを利用者に警告するスクリプトを提供するを参照)、このフォームを警告のダイアログから利用可能にする。どれぐらいの追加時間が必要かを示すことができるようにするか、繰り返し制限時間を延長できるようにすることによって、利用者はデフォルトの制限時間を少なくとも 10 倍延長することができる。

事例

ウェブページに最新の株式市場のデータがあり、定期的に更新されている。利用者が最初の更新の前に警告を受けたとき、利用者には更新の間隔を延長するための選択肢が提供されている。
オンラインチェスゲームにおいて、各プレーヤーはそれぞれの動きが終わるまでの制限時間が与えられている。動かせる時間がほとんど終わりであるという警告をプレーヤーが受けたとき、利用者には時間を増やすための選択肢が提供されている。

参考リソース

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

PHPBuilder Time-out Info

SCR16: 制限時間が切れようとしていることを利用者に警告するスクリプトを提供する

検証

手順

制限時間を強制するためにスクリプトを使用しているウェブページで、制限時間が切れるまで待つ。
制限時間を延長する選択肢が提供されているかどうかを判断する。

期待される結果

2.の結果が真であり、かつインタラクションを完了するために更なる時間が提供されている。

SCR2: キーボード及びマウスのイベントハンドラを両方とも使用する

適用 (対象)

スクリプトをサポートしている HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、マウスやフォーカスのイベントによって装飾画像が変化する、機器に依存しないイベントの使い方を説明することである。onmouseover や onmouseout イベントを使って、マウスがページ中のある要素に重なるか、又は離れたときに装飾画像が変化するようにする。また、onfocus や onblur イベントを使って、要素がフォーカスされたか、フォーカスを失ったかによって画像を変更する。

下記の例では、アンカー要素の前に装飾画像がある。利用者がアンカータグにマウスオーバーすると、アンカータグの前の装飾画像が変化する。また、マウスがアンカーを離れると、画像は元に戻る。同じ画像の変化は、利用者がキーボードを使ってアンカー要素にフォーカスしたときにも起こる。フォーカスされたときに画像が変化し、フォーカスを失ったときには元の画像に戻る。これは、アンカー要素に onmouseover、onmouseout、onfocus 及び onblur イベントハンドラを付加することで実現できる。このイベントハンドラは JavaScript の関数で updateImage() と呼ばれており、画像の src 属性を変更する。updateImage() は onmouseover、onmouseout、onfocus、及び onblur イベントの応答として呼ばれる。

それぞれの画像には固有の ID が与えられている。この ID はどちらの画像が使われるかを表す論理値とともに、updateImage() に渡される: updateImage(imgId, isOver);。論理値 true は、マウスがアンカー要素に乗った場合、又はそれがフォーカスされた場合に渡される。false は、マウスがアンカー要素から離れた場合、又はそれがフォーカスを失った場合に渡される。 updateImage() 関数は、画像の ID を使用して画像を読み込み、その後に論理値の状態に応じて src 属性を変更する。画像は装飾目的で使用されているので、alt 属性値は空であることに注意する。

注記: サイズの近い画像を使用し、画像要素では幅と高さの属性値を指定することが望ましい。これは、画像が更新されることによりページのレイアウトが変化してしまうことを防ぐ。例では、同一サイズの画像が使用されている。

事例

事例 1

コード例:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"  "http://www.w3.org/TR/html4/loose.dtd">
 <html lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
 <title>Changing Image Source in a Device Independent Manner</title>
 <script type="text/javascript">
 /* このfunctionは、img要素のsrc属性値を変更する。
  * param imgId - 変更する画像オブジェクトのID
  * param isOver - true: マウスオーバーしたとき、又はオブジェクトがフォーカスを受け取ったとき
  *                false: マウスオーバーを外したとき、又はフォーカスを外したとき
 */
 function updateImage(imgId, isOver) {
   var theImage = document.getElementById(imgId);
   if (theImage != null) { //could use a try/catch block for user agents supporting at least JavaScript 1.4
                           // These browsers support try/catch - NetScape 6, IE 5, Mozilla, Firefox
      if (isOver) {
        theImage.setAttribute("src","yellowplus.gif");
      }
      else {
        theImage.setAttribute("src","greyplus.gif");
      }
   }
 }
 </script>
 </head>
 <body>
 <p>Mouse over or tab to the links below and see the image change.</p>
 <a href="http://www.w3.org/wai" onmouseover="updateImage('wai', true);" onfocus="updateImage('wai', true);"
   onmouseout="updateImage('wai',false);" onblur="updateImage('wai',false);">
 <img src="greyplus.gif" border="0" alt="" id="wai">
   W3C Web Accessibility Initiative</a> &
 <a href="http://www.w3.org/International/" onmouseover="updateImage('i18n', true);" 
   onfocus="updateImage('i18n',true);" onmouseout="updateImage('i18n',false);"
   onblur="updateImage('i18n',false);">
   <img src="greyplus.gif" border="0" alt="" id="i18n">
   W3C Internationalization</a>
 </body>
 </html>

検証

手順

ウェブページを読み込み、マウス及びキーボードを用いてイベントを検証する。

ウェブページが読み込まれたとき、「通常の」画像が期待通りに表示されていることを確認する。
マウスを使用
1. イベントハンドラを含む要素の上にマウスを移動する (この事例ではアンカー要素)。画像が期待されている画像に変化することを確認する。
2. マウスを要素から外す。画像が「通常の」画像に戻ることを確認する。
キーボードを使用
1. キーボードを使ってイベントハンドラを含む要素にフォーカスを設定する。画像が期待されている画像に変化することを確認する。
2. キーボードを使って要素からフォーカスを外す (一般的には別の要素にフォーカスを移す)。画像が「通常の」画像に戻ることを確認する。
画像が変更されたときに、ページ上の他の要素のレイアウトに影響がないことを確認する。

期待される結果

上記の全ての結果が真である。

SCR14: 不可欠ではないアラートの表示を任意にするために、スクリプトを使用する

適用 (対象)

緊急ではない情報提供のアラートにスクリプトを使用するウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.4 (割り込み)
- クイックリファレンス 2.2.4 (割り込み)
- 達成基準 2.2.4 (割り込み)を理解する

解説

この達成方法の目的は、メッセージ (アラート) を含むダイアログを利用者に表示することである。アラートが表示されたとき、それがフォーカスされると、利用者はそれを閉じるためにダイアログの OK ボタンを押さなければならない。これらのアラートにフォーカスが移ってしまうと、特に、緊急ではない情報に使用されたとき、利用者の気が散ってしまうかもしれない。今日の名言、役に立つ小技、又は特定のイベントまでのカウントダウンなど、緊急ではない目的のアラートは、利用者がウェブページに提供された選択肢でそれらを有効にすることなしには現れないようにする。

この達成方法では、アラートを表示するかどうかの利用者の選択を保存する JavaScript のグローバル変数に割り当てる。初期値は false にする。ラッパー関数は、アラートを表示する前にこの変数の値をチェックするために作成される。alert() 関数を直接呼び出すよりもむしろ、アラートを表示するすべての呼び出しをこのラッパー関数にかけるようにする。ページの上部には、ページでのアラートの表示を利用者が有効にするためのボタンを提供する。この達成方法は訪問ベースで 1 回の訪問ごとに作動する。ページが読みこまれるたび、アラートは無効にされ、利用者は手動でそれらを有効にしなければならない。あるいは、コンテンツ制作者は、利用者の選択をセッションを越えて保存するためにクッキーを使用することができる。

事例

事例 1

以下のスクリプトは、利用者が「アラートを利用する」というボタンを選択するなら、10 秒ごとにアラートボックスに名言を表示する。利用者は再び「アラートを利用しない」を選択することで、名言のアラートボックスを非表示にすることができる。

コード例:


<script type="text/javascript">
var bDoAlerts = false;  // アラートを表示するかどうか指定するグローバル変数
/* アラートを有効／無効にする関数。
 * param ブーリアン型 bOn - trueでアラートを有効、falseで無効。
*/
function modifyAlerts(isEnabled) {
   bDoAlerts = isEnabled;
}
/* アラート表示のラッパー関数。bDoAlertsの値をチェックし
* bDoAlertsがtrueのときに alert() 関数を呼び出すだけ。
*/
function doAlert(aMessage) {
    if (bDoAlerts) {
       alert(aMessage);
    }
}
// 例 - 名言を表示するループ。
var gCounter = -1;  // カウンタを保存するグローバル変数
// quotes変数は名言のリストで初期化される
var quotes = new Array("quote 1", "quote 2", "quote 3", "quote 4", "quote 5");
function showQuotes() {
   if (++gCounter &amp;gt;= quotes.length) { //★「&amp;gt;」は「>」ではないでしょうか？★
     gCounter = 0;
   }
   doAlert(quotes[gCounter]);
   setTimeout("showQuotes();", 10000);
}
showQuotes();
</script>

ページの本文内には、アラートを有効にしたり無効する方法を含める。以下はひとつの例である:

コード例:


<body>
<p>Press the button below to enable the display of famous quotes 
using an alert box<br />
<button id="enableBtn" type="button" onclick="modifyAlerts(true);">
Turn Alerts On</button><br />
<button id="disableBtn" type="button" onclick="modifyAlerts(false);">
Turn Alerts Off</button></p>

このコードを実装したサンプル: アラートの実装例

検証

手順

JavaScript の alert を使用した緊急ではない中断をサポートするウェブページにおいて:

ウェブページを読み込んだとき、緊急ではないアラートが表示されないことを確認する。
緊急ではないアラートを有効にするメカニズムがあることを確認する。
緊急ではないアラートを有効にすると、アラートが表示されることを確認する。

期待される結果

JavaScript の alert を使用して緊急ではない中断をサポートするウェブページでは、上記の 1.、2 及び 3 の結果が真である。

SCR16: 制限時間が切れようとしていることを利用者に警告するスクリプトを提供する

適用 (対象)

スクリプトによって制御された制限時間

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.1 (タイミング調整可能)
- クイックリファレンス 2.2.1 (タイミング調整可能)
- 達成基準 2.2.1 (タイミング調整可能)を理解する
注記: この達成方法は、達成基準 2.2.1 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 2.2.1 を理解するを参照すること。

解説

この達成方法の目的は、インタラクションを完了させるための時間がほとんど無いことを利用者に通知することである。スクリプトによって、時間制限のある機能が提供される場合には、そのスクリプトは利用者に制限時間が迫っていることを警告する機能を含み、より多くの時間を要求するためのメカニズムを提供することができる。制限時間の 20 秒以上前に、そのスクリプトは制限時間が迫っている事を伝え、利用者がさらに時間を必要とするかどうかを尋ねる確認ダイアログを提供する。もし利用者の答えが「はい」の場合、制限時間をリセットする。もし利用者の答えが「いいえ」又は返答がない場合、制限時間の終了を許可する。

この達成方法は、window.setTimeout() メソッドで設定された制限時間に関係する。例えば、60 秒で制限時間が切れる設定の場合、制限時間を 40 秒に設定して、確認ダイアログを表示させることができる。確認ダイアログが表示された時、新しく時間制限が残り 20 秒に設定される。「制限時間の猶予期間」の満了時に、当初の設計では 60 秒の制限時間の満了の時にとられていたであろう処置がとられる。

事例

事例 1

ある株式市場相場ページは最新の統計を利用可能な状態を確保するため 5 分毎にページを更新するスクリプトを使用している。その 5 分間が終了する 20 秒前に、確認ダイアログが表示され、利用者がページを更新する前にもっと時間が必要かどうかを尋ねる。これにより、利用者に更新が差し迫っていることを認識させるとともに、もし希望するならそれを回避できるようにする。

コード例:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"<url>http://www.w3.org/TR/html4/loose.dtd">http://www.w3.org/TR/html4/loose.dtd</title>">
<html lang="en">
<head>

<title>Stock Market Quotes</title>
<script type="text/javascript">
<!--
function timeControl() {
	// タイマーを4分40秒に設定し、利用者に確認を求める
	setTimeout('userCheck()', 280000);
}
function userCheck() {
	// ページの再読み込みを20秒に設定する
	var id=setTimeout('pageReload()', 20000);
	// 利用者が「OK」を選択した場合、タイマーがリセットされる
	// それ以外の場合、サーバーによりページが再読み込みされる
	if (confirm("This page is set to refresh in 20 seconds. 
	Would you like more time?"))
	{
	clearTimeout(id);
	timeControl();
	}
}
function pageReload() {
	window.location.reload(true);
}
timeControl();
-->
</script>
</head>
<body>
<h1>Stock Market Quotes</h1>
...etc...
</body>
</html>

SCR1: 利用者が初期設定の制限時間を延長できるようにする

検証

手順

スクリプトによって時間制限を制御されているウェブページにおいて:

ページを読み込み、制限時間より 20 秒少ないタイマーを開始する。
タイマーが切れるとき、間近に迫った時間制限を警告する確認ダイアログが表示されることを確認する。

期待される結果

2. の結果が真である。

SCR18: クライアントサイドのバリデーション及びアラートを提供する

適用 (対象)

利用者の入力を検証するコンテンツ

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、クライアントサイドのスクリプトによって、各フィールドで利用者が入力する値を確認することである。エラーが見つかった場合、警告ダイアログを表示し、エラーの内容をテキストで示す。警告ダイアログを閉じるとともに、スクリプトによってキーボードフォーカスをエラーが起こったフィールドに移動させれば、それは利用者にとって役立つ。

事例

事例 1: イベントハンドラで単一のコントロールをチェックする

以下のスクリプトは、有効な日付がフォームのコントロールに入力されたかをチェックする。

コード例:


<label for="date">Date:</label>
<input type="text" name="date" id="date" 
onchange="if(isNaN(Date.parse(this.value))) 
alert('This control is not a valid date. 
Please re-enter the value.');" />

事例 2: 利用者がフォームを送信したときに複数のコントロールをチェックする

次の例はフォーム内の複数のコントロールを表している。form 要素は、利用者がフォームを送信しようとした際、検証スクリプトを実行するために、イベントハンドラを作成する onsubmit 属性を用いている。検証で問題がない場合、イベントは true を返し、フォームの送信を続行する。検証でエラーが検出された場合は、利用者が問題を修正できるようエラーメッセージを表示し、送信を取り消すために false を返す。

注記 1: この事例は簡潔さのためにアラートを用いて説明している。利用者により役立つ通知は、問題のあるコントロールをハイライトし、エラーの内容とデータの修正が必要なコントロールに移動する方法をページ上に示すことである。

注記 2: この事例では簡潔さのために form 要素に onsubmit 属性を用いているが、通常であればページがロードした際にフォーム送信用のイベントリスナーを作成する。

スクリプトコード:


function validate() {
	// initialize error message
	var msg = "";
	
	//validate name
	var pattern = /^[a-zA-Z\s]+$/;
	var el = document.getElementById("name");
	if (!pattern.test(el.value))  msg += "Name can only have letters and spaces. ";
	
	// validate number
	var pattern = /^[\d\-+\.\s]+$/;
	var el = document.getElementById("tel");
	if (!pattern.test(el.value))  msg += "Telephone number can only have digits and separators. ";
	
	if (msg != "") {
		alert(msg);
		return false;
	} else return true;
}

フォームコード:


<form action="multiple-controls.html" onsubmit="return validate()">
	<p>
		<label for="name">Name: </label>
		<input type="text" name="name" id="name" />
	</p>
	<p>
		<label for="tel">Telephone number: </label>
		<input type="text" name="tel" id="tel" />				
	</p>
	<p>
		<input type="submit" />
	</p>
</form>

利用者がフォームを送信したときに複数のコントロールをチェックする実装例にこの実装方法のデモがある。

G89: 期待されるデータ書式及び入力例を提供する

検証

手順

特定の入力を必要とするフォームのフィールドに対して:

無効なデータを入力する。
エラーを説明している警告が提供されているかどうかを判断する。

期待される結果

2. の結果が真である

SCR19: select 要素の onchange イベントは、コンテキストの変化を引き起こすことのないように使用する

適用 (対象)

スクリプトをサポートする HTML 及び XHTML。この達成方法では、JavaScript 1.4 の try/catch 構文を用いる。

これは、次の達成基準に関連する達成方法である:

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

SCR19 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、ウェブページの他の要素を更新する select 要素において onchange イベントを正しく使用する方法を示すことである。この達成方法は、コンテキストの変化を引き起こさない。ウェブページに一つかそれ以上の select 要素があるとき、一方の onchange イベントは、そのウェブページの別の select 要素における選択肢を更新できる。そして、select 要素によって必要とされるデータのすべてが、ウェブページの中に含まれている。

ウェブページでの音声読み上げ順序において、選択によって変更されるアイテムが、トリガーとなる select 要素の後にあることに注意することが重要である。これは、支援技術が変化を察知するのを確実にし、変更されたアイテムがフォーカスされたとき、利用者は新しいデータを認識する。なお、この達成方法は、ユーザエージェントによる JavaScript のサポート状況に依存する。

事例

事例 1

この事例には、二つの select 要素がある。最初の select 要素でアイテムが選択されたとき、二つめの select 要素の選択肢が適切に更新される。最初の select 要素には、大陸のリストがある。そして、二つめの select 要素には、選択された大陸に位置する国々の一部のリストがある。onchange イベントは、大陸の選択に連動している。大陸の選択が変わると、国の選択肢は、ドキュメントオブジェクトモデル (DOM) を通して JavaScript を用いて変更される。必要であるすべてのデータ、国と大陸のリスト、はウェブページの中に含まれている。

以下のコードの概要:

トリガーとなる select 要素の大陸ごとの国々のリストを含む countryLists 配列
大陸の select 要素の onchange イベントによって呼ばれる countryChange() 関数
ウェブページの本文の select 要素を作成する XHTML コード

コード例:


<?xml version="1.0" encoding="UTF-8"?> 
<!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" xml:lang="en" lang="en"> 
  <head> 
    <meta http-equiv="content-type" content="text/xhtml; charset=utf-8" /> 
    <title>Dynamic Select Statements</title> 

<script type="text/javascript">
 //<![CDATA[ 
 // 国の選択項目のリストに現れるのと同じ順の選択可能な国の配列 
 var countryLists = new Array(4) 
 countryLists["empty"] = ["Select a Country"]; 
 countryLists["North America"] = ["Canada", "United States", "Mexico"]; 
 countryLists["South America"] = ["Brazil", "Argentina", "Chile", "Ecuador"]; 
 countryLists["Asia"] = ["Russia", "China", "Japan"]; 
 countryLists["Europe"]= ["Britain", "France", "Spain", "Germany"]; 
 /* CountryChange() はselect要素のonchangeイベントから呼び出される。 
 * param selectObj - onchangeイベントで生成されるselectオブジェクト。
 */ 
 function countryChange(selectObj) { 
 // 選択された選択肢のインデックスを得る 
 var idx = selectObj.selectedIndex; 
 // 選択された選択肢の値を得る 
 var which = selectObj.options[idx].value; 
 // countryLists 配列から項目のリストを検索するために選択された選択肢の値を使う 
 cList = countryLists[which]; 
 // そのIDを通して国のselect要素を得る
 var cSelect = document.getElementById("country"); 
 // 国のリストから現在の選択肢を削除する 
 var len=cSelect.options.length; 
 while (cSelect.options.length > 0) { 
 cSelect.remove(0); 
 } 
 var newOption; 
 // 新しい選択肢を生成する 
 for (var i=0; i<cList.length; i++) { 
 newOption = document.createElement("option"); 
 newOption.value = cList[i];  // 選択肢の文字列と値は同じとする 
 newOption.text=cList[i]; 
 // 新しい選択肢を追加する 
 try { 
 cSelect.add(newOption);  // これはDOMをサポートするブラウザでは失敗するが、IEには必要 
 } 
 catch (e) { 
 cSelect.appendChild(newOption); 
 } 
 } 
 } 
//]]>
</script>
</head>
<body>
  <noscript>This page requires JavaScript be available and enabled to function properly</noscript>
  <h1>Dynamic Select Statements</h1>
  <label for="continent">Select Continent</label>
  <select id="continent" onchange="countryChange(this);">
    <option value="empty">Select a Continent</option>
    <option value="North America">North America</option>
    <option value="South America">South America</option>
    <option value="Asia">Asia</option>
    <option value="Europe">Europe</option>
  </select>
  <br/>
  <label for="country">Select a country</label>
  <select id="country">
    <option value="0">Select a country</option>
  </select>
</body>
 </html>

このコードの実装サンプル: 動的なセレクトメニュー

参考リソース

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

Accessible Forms using WCAG 2.0

(今のところ、なし。)

検証

手順

トリガーとなる select 要素 (この事例では、大陸を選択するセレクトメニュー) に移動し、選択肢の値を変える。
トリガーによって更新された select 要素 (この事例では、国を選択するセレクトメニュー) へ移動する。
一致する選択肢の値が、他の select 要素に表示されていることを確認する。
トリガーとなる select 要素へ移動し、選択肢へ移動するが、値を変えない。
一致する選択肢の値が、関連付けられた要素にまだ表示されていることを確認する。

関連付けられた要素の変化が認識されることを確かめるために、select 要素を支援技術を用いて検証することが望ましい。

期待される結果

3. 及び 5. の結果が真である。

SCR20: キーボードとその他のデバイス固有の機能を両方とも使用する

適用 (対象)

機能を実装するためにスクリプトを用いる全てのコンテンツ

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、イベントと関連付けられたスクリプト機能を含むコードを伴った、キーボード固有及びマウス固有のイベント双方の使用を明示することである。キーボード固有及びマウス固有のイベントを一緒に用いることにより、さまざまな種類の機器でコンテンツを操作できることを保証することができる。例えば、スクリプトが keypress を認識したときに、マウスボタンをクリックしたときと同じ動作を行うことができるようにする。このテクニックにより、キーボードによるアクセスだけでなく他の機器によるアクセスの達成基準を満たすことができる。

JavaScript でよく使用されるイベントハンドラには、onblur、onchange、onclick、ondblclick、onfocus、onkeydown、onkeypress、onkeyup、onload、onmousedown、onmousemove、onmouseout、onmouseover、onmouseup、onreset、onselect、onsubmit、onunload が含まれる。いくつかのマウス固有の機能には、論理的に対応するキーボード固有の機能がある (例えば 'onmouseover' と 'onfocus' のように)。キーボード向けのイベントハンドラは、対応するマウス向けの機能とともに提供すべきである。

次の表は、マウスイベントハンドラに対応するキーボードイベントハンドラの候補である。

対応表
マウス向け	キーボード向け
`mousedown`	`keydown`
`mouseup`	`keyup`
`click` ^[1]	`keypress` ^[2]
`mouseover`	`focus`
`mouseout`	`blur`

¹ click は基本的にはマウスのイベントハンドラであるが、ほとんどの HTML 及び XHTML 向けのユーザエージェントは、HTML のネイティブコントロール (例: ボタン又はリンク) が有効化された場合、マウス又はキーボードのどちらで有効化されたかにかかわらず、イベントを処理することができる。そのため、もともとフォーカスできる HTML 要素にハンドラを追加するときは、実際にはキーボード用のイベントを補完する必要はない。しかし、下記の事例 2 のように他のイベントにハンドラを追加するときは、必要である。

² keypress イベントハンドラは、どのキーに対しても有効であることから、そのイベントハンドラ関数では、イベントを処理する前に、Enter キーが押されたかどうかをチェックすべきである。そうでなければ、イベントハンドラは利用者が任意のキーを押すたびに実行され、コントロールから抜けるために Tab キーを押すような場合にも実行されるので、通常は望ましくない。

(dblclick 及び mousemove のような) いくつかのマウス固有の機能には、対応するキーボード固有の機能がない。つまり、いくつかの機能は機器別に違った実装をしなければならないということである (例えば、実装されているマウス固有の機能と同等の機能を、キーボードから実行するための一連のボタン操作を含むようにする)。

事例

事例 1

この画像リンクの例では、利用者がポインタを画像に重ねると画像が変化する。キーボード利用者に同様の体験を提供するには、利用者が画像リンクに Tab キーで移動した場合に、画像を変化させればよい。

コード例:


<a href="menu.php" onmouseover="swapImageOn('menu')" onfocus="swapImageOn('menu')" 
onmouseout="swapImageOff('menu')" onblur="swapImageOff('menu')"> 
<img id="menu" src="menu_off.gif" alt="Menu" /> 
</a>

事例 2

この事例では、マウスとキーボードの両方を用いて機能を実行できる画像のカスタムコントロールを紹介している。マウスイベントの onclick は、対応するキーボードイベントの onkeypress によって補完されている。tabindex 属性は、キーボードを用いて Tab キーで移動した際に、画像の上で停止させるためのものである。この事例では nextPage() 関数が、押されたキーボードのキーがEnterであることを確認すべきであり、そうでない場合は、画像がフォーカスを持つ間にすべてのキーボード動作に応答するが、これは期待される動作ではないことに注意する。

コード例:


<img onclick="nextPage();" onkeypress="nextPage();" tabindex="0" src="arrow.gif" 
alt="Go to next page">

注記: この例では img 要素に tabindex を用いている。現時点では (文法的に) 妥当ではないが、この機能を実装するための古典的なテクニックとして用いられている。このようなカスタムコントロールでは、コントロールの役割 (role) と状態 (state) を支援技術に引き渡すために WAI-ARIA も用いるべきである。

参考リソース

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

Overview of Creating Accessible JavaScript

G90: キーボードがトリガーとなるイベントハンドラを提供する

検証

手順

全てのインタラクティブな機能を探す。
それらのインタラクティブな機能全てに、キーボードだけを使ってアクセスできることを確認する。

期待される結果

2. の結果が真である

SCR21: ページにコンテンツを追加するために、Document Object Model (DOM) の機能を使用する

適用 (対象)

HTML 及び XHTML の中で利用される ECMAScript

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

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

SCR21 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、document.write 又は object.innerHTML の代わりに Document Object Model (DOM) の機能を用いて、ページ中にコンテンツを追加することである。document.write() メソッドは XHTML で正しい MIME タイプ (application/xhtml+xml) が指定されているときに動作せず、innerHTML プロパティは DOM の仕様ではないため利用すべきでない。もし DOM の機能を利用してコンテンツを追加すれば、ユーザエージェントは DOM にアクセスしてコンテンツを取り込むことができる。createElement() 関数を使って DOM の中に要素を作成することもできる。createTextNode() は要素に関連付けられたテキストを作成するのに用いられる。appendChild()、removeChild()、insertBefore() 及び replaceChild() 関数は、要素やノードを追加したり削除したりするのに用いられる。その他の DOM 関数は、作成された要素に属性を与えるときに使用される。

注記: フォーカス可能な要素を文書に追加するとき、tabindex 属性を用いて明示的なタブ順序を指定してはならない。なぜなら、文書の中央にフォーカス可能な要素を追加するときに問題が発生するからである。tabindex 属性を明示的に設定しないことで、デフォルトのタブ順序が新しい要素に割り当てられるようにする。

訳注 1: HTML 5.2§7.4.3. document.write() の Warning でも述べられているように、たとえ HTML (MIME タイプ text/html) であっても document.write() の使用は勧められていない。

訳注 2: innerHTML は 2018 年現在、DOM Parsing and Serialization 仕様で定義されている。

訳注: WAIC では SCR21 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: SCR21 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例

事例 1

この例では、クライアントサイドスクリプトの使用法として、フォームの検証方法を紹介している。もしエラーがみつかれば、適切なエラーメッセージが表示される。この例では DOM 関数を使用し、タイトル、エラーに関する短い説明、及びエラー一覧の順序付リストを含むエラー通知を追加している。タイトルの内容はリンクとして書かれているので、focus メソッドを使って利用者の注意をエラーに向けることができる。個別のリスト項目もまた、リンクとして書かれているので、そのリンク先に移動したときにエラーのあるフォームのフィールドにフォーカスできるように書かれている。

この例では、簡単にするために二つのテキストフィールドだけを検証しているが、一般的なフォームハンドラにするために容易に拡張することができる。クライアントサイドの検証は、それを唯一の検証とすべきではなく、サーバーサイドの検証でも確認するべきである。クライアントサイドでの検証の利点は、利用者にすぐにフィードバックを提供することで、サーバーからエラーが帰ってくるまでの間、彼らを待たせることがないこと、及びサーバーへの余計なトラフィックを軽減できることである。

次の例はフォームにイベントハンドラを追加するスクリプトである。もしスクリプトが有効であれば、サーバーにフォームが送信される前に validateNumbers() 関数がクライアントサイドの検証のために呼び出される。もしスクリプトが有効でなければ、フォームはすぐにサーバー側に送信されるので、検証機能はサーバーにも実装されるべきである。

コード例:


window.onload = initialise;
function initialise()
{
  // 標準に準拠したユーザエージェントが対象
  if (!document.getElementById || !document.createElement || !document.createTextNode)
    return;

  // フォームにイベントハンドラを付加
  var objForm = document.getElementById('numberform');
  objForm.onsubmit= function(){return validateNumbers(this);};
}

次の例は validation の機能である。エラーメッセージの要素を作成するために createElement()、createTextNode()、及び appendChild() DOM 関数を使用しているところに注目して欲しい。

コード例:


function validateNumbers(objForm)
{
  // フィールドを検証
  var bFirst = isNumber(document.getElementById('num1').value);
  var bSecond = isNumber(document.getElementById('num2').value);
  // 問題がある場合、エラーを表示
  if (!bFirst || !bSecond)
  {
    var objExisting = document.getElementById('validationerrors');
    var objNew = document.createElement('div');
    var objTitle = document.createElement('h2');
    var objParagraph = document.createElement('p');
    var objList = document.createElement('ol');
    var objAnchor = document.createElement('a');
    var strID = 'firsterror';
    var strError;
    // 見出し要素にリンクを含めることによって、スクリーンリーダーは
    // フォーカスを置くことができる － そのリンク先はエラー一覧の中で 
    // 一番最初のエラー項目とする
    objAnchor.appendChild(document.createTextNode('Errors in Submission'));
    objAnchor.setAttribute('href', '#firsterror');
    objTitle.appendChild(objAnchor);
    objParagraph.appendChild(document.createTextNode('Please review the following'));
    objNew.setAttribute('id', 'validationerrors');
    objNew.appendChild(objTitle);
    objNew.appendChild(objParagraph);
    // 発見したエラーすべてをエラー一覧に追加
    if (!bFirst)
    {
      strError = 'Please provide a numeric value for the first number';
      objList.appendChild(addError(strError, '#num1', objForm, strID));
      strID = '';
    }
    if (!bSecond)
    {
      strError = 'Please provide a numeric value for the second number';
      objList.appendChild(addError(strError, '#num2', objForm, strID));
      strID = '';
    }
    // エラー情報に一覧を追加
    objNew.appendChild(objList);
    // 既存のエラーがあった場合、新規のエラーと置き換える
    // あるいは、新規のエラーをフォームの先頭に追加する
    if (objExisting)
      objExisting.parentNode.replaceChild(objNew, objExisting);
    else
    {
      var objPosition = objForm.firstChild;
      objForm.insertBefore(objNew, objPosition);
    }
    // フォーカスを見出しにあるアンカーに置いて、スクリーンリーダーに
    // 対してエラーがあることを警告する
    objAnchor.focus();
    // フォームを送信しない
    objForm.submitAllowed = false;
    return false;
  }
  return true;
}

// 数字を検証する関数
function isNumber(strValue)
{
  return (!isNaN(strValue) &amp;&amp; strValue.replace(/^\s+|\s+$/, '') !== '');
}

以下は、エラーメッセージを作成して、関連するフォームのフィールドにフォーカスさせるための補助関数である。

コード例:


// エラー内容を説明する、エラーのフォームフィールドへのリンクの
// リスト項目を作成する関数
function addError(strError, strFragment, objForm, strID)
{
  var objAnchor = document.createElement('a');
  var objListItem = document.createElement('li');
  objAnchor.appendChild(document.createTextNode(strError));
  objAnchor.setAttribute('href', strFragment);
  objAnchor.onclick = function(event){return focusFormField(this, event, objForm);};
  objAnchor.onkeypress = function(event){return focusFormField(this, event, objForm);};
  // strIDに値がある場合、これがリストで一番目のエラーとなる
  if (strID.length > 0)
    objAnchor.setAttribute('id', strID);
  objListItem.appendChild(objAnchor);
  return objListItem;
}

// エラーのフォームフィールドにフォーカスを置く関数
function focusFormField(objAnchor, objEvent, objForm)
{
  // キーボードナビゲーションを可能にするAllow keyboard navigation over links
  if (objEvent &amp;&amp; objEvent.type == 'keypress')
    if (objEvent.keyCode != 13 &amp;&amp; objEvent.keyCode != 32)
      return true;
  // フォーカスをフォームコントロールに設定する
  var strFormField = objAnchor.href.match(/[^#]\w*$/);
  objForm[strFormField].focus();
  return false;
}

以下は事例のフォーム用 HTML である。

コード例:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
	<title>ECMAScript Form Validation</title>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
	<script type="text/javascript" src="validate.js"></script>
</head>
<body>
<h1>Form Validation</h1>
<form id="numberform" method="post" action="form.php">
<fieldset>
<legend>Numeric Fields</legend>
<p>
<label for="num1">Enter first number</label>
<input type="text" size="20" name="num1" id="num1">
</p>
<p>
<label for="num2">Enter second number</label>
<input type="text" size="20" name="num2" id="num2">
</p>
</fieldset>
<p>
<input type="submit" name="submit" value="Submit Form">
</p>
</form>
</body>
</html>

この例はクライアントサイドスクリプトに限定しているため、サーバーサイドの検証によって補完されるべきである。例では、クライアントサイドスクリプトが利用できるときのエラーメッセージの作成に限定される。

このコードの実装サンプル: フォームの検証

参考リソース

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

HTML 4.01 The Document Object Model, More methods from Webreference.com
Accessible Forms using WCAG 2.0

(今のところ、なし。)

検証

手順

動的に新しいコンテンツを作成するページに対して:

ソースコードを検証して、新しいコンテンツが document.write()、innerHTML、outerHTML、innerText 又は outerText を用いて作成されていないことを確認する。

訳注: 解説の訳注で示した document.write()、innerHTML に加えて、outerHTML は 2018 年現在、DOM Parsing and Serialization 仕様で定義されており、innerText は HTML 5.2§3.2.6. The innerText IDL attribute で定義されている。したがって、手順 1 に示されるものに関しては、outerText のみが非標準である。HTMLElement.outerText - Web APIs | MDN も参照のこと。

期待される結果

1. の結果が真である。

SCR22: 点滅を制御し、5 秒以内に停止させるために、スクリプトを使用する

適用 (対象)

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

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.2 (一時停止、停止、非表示)
- クイックリファレンス 2.2.2 (一時停止、停止、非表示)
- 達成基準 2.2.2 (一時停止、停止、非表示)を理解する

解説

この達成方法の目的は、スクリプトによる点滅を、5 秒未満で停止する設定にできるよう制御することである。スクリプトを用いて、コンテンツの点滅効果を開始し、表示と非表示の状態切り替えを制御し、そして 5 秒以下で停止させる。setTimeout() 関数を用いて、点滅するコンテンツの表示と非表示の状態を切り替え、点滅の回数と所要時間の積が 5 秒近くになった時に停止させる。

事例

事例 1

この例では、JavaScript を用いて HTML 及び XHTML コンテンツの点滅を制御する。JavaScript は、コンテンツの表示状態を制御して点滅効果を生みだす。効果の開始を制御し、5 秒以内に停止させる。

コード例:

...
<div id="blink1" class="highlight">New item!</div>
<script type="text/javascript">
<!--
// 点滅「on」状態
function show()
{
	if (document.getElementById)
	document.getElementById("blink1").style.visibility = "visible";
}
// 点滅「off」状態
function hide()
{
	if (document.getElementById)
	document.getElementById("blink1").style.visibility = "hidden";
}
// 点滅効果を出すために「on」と「off」の状態を450ミリ秒ごとに切り替え
// 4500ミリ秒後に終了 (5秒未満)
for(var i=900; i < 4500; i=i+900)
{
	setTimeout("hide()",i);
	setTimeout("show()",i+450);
}
-->
</script>
...

このコードの実装サンプル: 点滅をコントロールするために、スクリプトを使用する

検証

手順

点滅しているコンテンツのそれぞれの箇所に対して:

点滅効果が開始される時、5 秒間のタイマーを開始させる。
タイマーが切れるとき、点滅が停止している。

期待される結果

点滅しているコンテンツのそれぞれの箇所に対して、2. の結果が真である。

SCR24: 利用者の要求に応じて新しいウィンドウを開くために、プログレッシブエンハンスメントを使用する

適用 (対象)

HTML 4.01 及び XHTML 1.0

訳注: HTML4 及び XHTML 1.0 は Superseded Recommendation としてマークされ、廃止された仕様である。

これは、次の達成基準に関連する達成方法である:

達成基準 3.2.5 (要求による変化)
- クイックリファレンス 3.2.5 (要求による変化)
- 達成基準 3.2.5 (要求による変化)を理解する

解説

この達成方法の目的は、利用者が要求していない新しいウィンドウの出現によって引き起こされうる混乱を回避することである。突然新しいウィンドウが開くと、利用者は混乱したり、そのことに気づかなかったりする。文書型が target 属性を認めていない場合 (HTML 4.01 Strict や XHTML 1.0 Strict には存在しない)、又はコンテンツ制作者が target 属性の使用を好まない場合には、ECMAScript を用いて新しいウィンドウを開くことができる。以下にある事例は、スクリプトを用いて新しいウィンドウを開く方法を示している。その事例では、リンク (a 要素) にイベントハンドラを追加して、利用者にリンク先のコンテンツが新しいウィンドウで開くことを事前に知らせている。

事例

事例 1

マークアップ:

スクリプトはドキュメントの head 要素内に組み込まれており、リンクにはスクリプトのフックとなる id 属性がある。

コード例:


<script type="text/javascript" src="popup.js"></script>
…
<a href="help.html" id="newwin">Show Help</a>

スクリプト:

コード例:


// ブラウザによるイベント登録のサポートは不十分だが
// 従来のイベントモデルを用いる
window.onload = addHandlers;

function addHandlers()
{
  var objAnchor = document.getElementById('newwin');

  if (objAnchor)
  {
    objAnchor.firstChild.data = objAnchor.firstChild.data + ' (opens in a new window)';
    objAnchor.onclick = function(event){return launchWindow(this, event);}
    // UAAG ではユーザエージェントにデバイス非依存な方法でイベントを処理することを
    // 要求しているが、そうしないブラウザが多いのでキーボードイベントを追加する
    objAnchor.onkeypress = function(event){return launchWindow(this, event);}
  }
}

function launchWindow(objAnchor, objEvent)
{
  var iKeyCode, bSuccess=false;

  // キーボードからのイベントである場合、利用者がリンクをリクエストしたときだけ
  // 新しいウィンドウを開くようにする (リターン又はスペース)
  if (objEvent &amp;&amp; objEvent.type == 'keypress')
  {
    if (objEvent.keyCode)
      iKeyCode = objEvent.keyCode;
    else if (objEvent.which)
      iKeyCode = objEvent.which;

    // キャリッジリターン又はスペースではない場合、ユーザエージェントが
    // アクションの処理を継続するようにtrueを返す
    if (iKeyCode != 13 &amp;&amp; iKeyCode != 32)
      return true;
  }

  bSuccess = window.open(objAnchor.href);

  // ウィンドウが開かなかった場合、ブラウザには同じウィンドウで開くという
  // デフォルトのアクションを継続させる
  if (!bSuccess)
    return true;

  // ウィンドウが開いたら、ブラウザによる処理をそこで止める
  return false;
}

参考リソース

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

Wikipedia: Progressive Enhancement

H83: 利用者の要求に応じて新しいウィンドウを開くために target 属性を使用して、そのことをリンクテキストで明示する

検証

手順

ドキュメントにあるリンクを起動して、新しいウィンドウが開くかどうかを確認する。
新しいウィンドウを開くリンクごとに、次のいずれかを達成するためにスクリプトを用いることを確認する:
1. リンクが新しいウィンドウを開くことを明示している
2. デバイス非依存のイベントハンドラを用いている
3. 新しいウィンドウを開けない場合、ブラウザが同じウィンドウにリンク先のコンテンツを開くことができる。

期待される結果

2.の結果が真である。

SCR26: 動的なコンテンツを、Document Object Model の、そのトリガーとなる要素の直後に挿入する

適用 (対象)

HTML 及び XHTML、スクリプト

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.3 (フォーカス順序)
- クイックリファレンス 2.4.3 (フォーカス順序)
- 達成基準 2.4.3 (フォーカス順序)を理解する

解説

この達成方法の目的は、Document Object Model (DOM) に挿入されたユーザインタフェースの要素をタブ順序及びスクリーンリーダーの読み上げ順序がユーザエージェント標準のふるまいによって正しく設定されるような方法で配置することである。この達成方法は、メニューやダイアログのように隠れているものと表示されているもの、全てのユーザインタフェース要素に利用することができる。

スクリーンリーダーの読み上げ順序は、Document Object Model 内の HTML 又は XHTML の要素の順序に基づいており、それはタブ順序についても同様である。この達成方法では、新しいコンテンツを DOM のそのトリガーとなる要素の直後に挿入する。トリガーとなる要素は、リンク又はボタンでなければならず、スクリプトはその onclick イベントにより呼び出されなければならない。これらの要素はもともとフォーカス可能であり、その onclick イベントはデバイスに依存しない。フォーカスは選択された要素に残り、その後に挿入された新しいコンテンツは、タブ順序及びスクリーンリーダーの読み上げ順序の両方において、次の順番となる。

この達成方法は同期された更新にも利用できることに注目して欲しい。(AJAX と呼ばれることのある) 非同期の更新では、支援技術に非同期のコンテンツが挿入されたことを通知するために追加の達成方法が必要となる。

訳注: WAIC では SCR26 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: SCR26 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例

事例 1

この例では、リンクがクリックされた際にメニューを生成し、そのリンクの後に挿入する。リンクの onclick イベントは新しいメニューのための ID をパラメータとして渡す ShowHide スクリプトを呼び出すために使用される。

コード例:

<a href="#" onclick="ShowHide('foo',this)">Toggle</a>

ShowHide スクリプトは新しいメニューを含む div を生成し、リンクを挿入する。最終行がスクリプトの核心となる。スクリプトのトリガーとなる要素の親を探し、新しい子として生成された div をそれに追加する。これにより、新しい div は DOM 内でリンクの次になる。利用者がタブを押したときには、フォーカスがメニュー内で最初のフォーカス可能な項目となる生成されたリンクに移動する。

コード例:


function ShowHide(id,src)
{
	var el = document.getElementById(id);
	if (!el)
	{
		el = document.createElement("div");
		el.id = id;
		var link = document.createElement("a");
		link.href = "javascript:void(0)";
		link.appendChild(document.createTextNode("Content"));
		el.appendChild(link);
		src.parentElement.appendChild(el);
	}
	else
	{
		el.style.display = ('none' == el.style.display ? 'block' : 'none');
	}
}

CSS は div およびリンクをメニューのように見せるために利用される。

検証

手順

ポップアップではないダイアログのトリガーとなる全てのエリアを探す。
そのダイアログがボタン又はリンクのクリックイベントによりトリガーされる。
スクリプトによって生成された DOM を調査できるツールを使って、ダイアログが DOM 内で次の位置にきている。

期待される結果

2. 及び 3. の結果が真である。

SCR27: Document Object Model を用いて、ページ上にある複数のセクションを並び替える

適用 (対象)

HTML および XHTML、スクリプト

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.3 (フォーカス順序)
- クイックリファレンス 2.4.3 (フォーカス順序)
- 達成基準 2.4.3 (フォーカス順序)を理解する

解説

この達成方法の目的は、コンポーネントを再配置するための極めてユーザブルかつアクセシブルなメカニズムを提供することである。再配置するためのメカニズムのうち、もっとも一般的なものは、コンポーネントに番号をつけることができる設定ページに利用者を送ること、又は、コンポーネントをドラッグ＆ドロップして希望する位置へ移動できるようにすることのふたつである。ドラッグ＆ドロップの方が、ひとつずつ項目を適当な位置に並べることができ、結果を感覚的に得られるため、はるかにユーザブルな方法である。残念なことに、ドラッグ＆ドロップはマウスの利用に頼った方法である。この達成方法は、利用者がコンポーネントのメニューを使って、それらを機器に依存することなく適当な位置に再配置することを可能にする。ドラッグ＆ドロップによる再配置機能の代替として、もしくはそれと併用して利用することができる。

メニューはリンクリストで、コンテンツを再配置するスクリプトのトリガーとなる、機器に依存しない onclick イベントを使用している。コンテンツは単に視覚的にだけでなく、Document Object Model (DOM) でも再配置されているので、すべての機器向けに正しい順序となっている。

事例

事例 1

この例は上下間の再配置を行う。このアプローチはまた、右と左のオプションを追加することで、2 次元での再配置にも利用できる。

この例のコンポーネントは順序無しリストのリスト項目である。順序無しリストは、こうしたコンポーネントのような類似項目のためのとてもよいセマンティックモデルである。メニューを使う方法も、他のタイプのグループ化に使用できる。

モジュールはリスト項目であり、それぞれのモジュールは、div 要素内のコンテンツに加えて、入れ子になったリストとして表されたメニューを含んでいる。

コード例:

<ul id="swapper">
    <li id="black">
        <div class="module">
            <div class="module_header">
                <!-- menu link -->
                <a href="#" onclick="ToggleMenu(event);">menu</a>
                <!-- menu -->
                <ul class="menu">
                    <li><a href="#" onclick="OnMenuClick(event)" 
                        onkeypress="OnMenuKeypress(event);">up</a></li>
                    <li><a href="#" onclick="OnMenuClick(event)" 
                        onkeypress="OnMenuKeypress(event);">down</a></li>
                </ul>
            </div>
            <div class="module_body">
                Text in the black module
            </div>
        </div>
    </li>
    ...
</ul>

ここまでは、簡単なツリーの例でメニューを出したり隠したりする方法をとりあげてきたので、モジュールを入れ替えるコードについても着目する。イベントを同期させてデフォルトのリンクアクションをキャンセルしてから、作業に移動する。最初に、これから作業する要素、メニュー、再配置されるモジュール、メニューリンクのための一連のローカル変数をセットする。それから、再配置の方向を確認した後に、入れ替えるノードの取得を試みる。ノードを見つけた場合、swapNode() を呼び出して二つのモジュールを入れ替え、 PositionElement() でモジュールと共に絶対配置されたメニューを移動し、すべてが完了したメニュー項目にフォーカスを設定する。

コード例:

function MoveNode(evt,dir)
{
    HarmonizeEvent(evt);
    evt.preventDefault();

    var src = evt.target;
    var menu = src.parentNode.parentNode;
    var module = menu.parentNode.parentNode.parentNode;
    var menuLink = module.getElementsByTagName("a")[0];
    var swap = null;
    
    switch(dir)
    {
        case 'up':
        {
            swap = module.previousSibling;
            while (swap &amp;&amp; swap.nodeType != 1)
            {
                swap = swap.previousSibling;
            }
            break;
        }
        case 'down':
        {
            swap = module.nextSibling;
            while (swap &amp;&amp; swap.nodeType != 1)
            {
                swap = swap.nextSibling;
            }
            break;
        }
    }
    if (swap &amp;&amp; swap.tagName == node.tagName)
    {
        module.swapNode(swap);
        PositionElement(menu,menuLink,false,true);
    }
    src.focus();
}

ノード入れ替えの CSS は、モジュール及び小さなメニューのサイズや色の調整だけで、前のツリーの例と大きな違いはない。

コード例:


ul#swapper { margin:0px; padding:0px; list-item-style:none; }
ul#swapper li { padding:0; margin:1em; list-style:none; height:5em; width:15em; 
    border:1px solid black; }
ul#swapper li a { color:white; text-decoration:none; font-size:90%; }

ul#swapper li div.module_header { text-align:right; padding:0 0.2em; }
ul#swapper li div.module_body { padding:0.2em; }

ul#swapper ul.menu { padding:0; margin:0; list-style:none; background-color:#eeeeee; 
    height:auto; position:absolute; text-align:left; border:1px solid gray; display:none; }
ul#swapper ul.menu li { height:auto; border:none; margin:0; text-align:left; 
    font-weight:normal; width:5em; }
ul#swapper ul.menu li a { text-decoration:none; color:black; padding:0 0.1em; 
    display:block; width:100%; }

検証

手順

ドラッグ＆ドロップで再配置可能なウェブユニット内のすべてのコンポーネントを探す。
リンクのリストで構成されたメニューを用いて、それらが再配置可能なメカニズムがあることを確認する。
メニューが DOM 内の再配置可能な項目の中に含まれていることを確認する。
再配置のスクリプトはリンクの onclick イベントだけをトリガーにしていることを確認する。
視覚的にだけではなく、項目が DOM の中でも再配置されていることを確認する。

期待される結果

2.～5. の結果が真である。

SCR28: コンテンツのブロックをバイパスするために、展開可能及び折り畳み可能なメニューを使用する

適用 (対象)

クライアントサイドスクリプティングを提供するウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.1 (ブロックスキップ)
- クイックリファレンス 2.4.1 (ブロックスキップ)
- 達成基準 2.4.1 (ブロックスキップ)を理解する

解説

この達成方法は、繰り返される構成要素を利用者のコントロールの下でメニューを展開したり折りたたんだりできるメニューの中に置くことで、その構成要素をスキップできるようにする。利用者は、メニューを折りたたむことで繰り返される構成要素をスキップできる。利用者は、メニューの要素を隠したり削除したりするユーザインタフェースを呼び出すことができる。関連情報には、ナビゲーションをスキップするメカニズムを提供するために利用できるメニュー、ツールバー及びツリーの達成方法をいくつか挙げている。

注記: 類似の方法は、サーバーサイドスクリプティングを用いて修正後のウェブページを読み込むことでも実装できる。

事例

事例 1

ウェブページの先頭にあるナビゲーションリンクは、すべて HTML、CSS 及び JavaScript を用いて実装されているメニュー項目である。ナビゲーションバーが展開しているとき、ナビゲーションのリンクは利用可能になっている。ナビゲーションバーがたたまれているとき、リンクは利用不可能である。

コード例:


...

  <script type="text/javascript">
  function toggle(id){
    var n = document.getElementById(id);
    n.style.display =  (n.style.display != 'none' ? 'none' : '' );
  }
  </script>

...

  <a href="#" onclick="toggle('navbar')">Toggle Navigation Bar</a>
  
  <ul id="navbar">
  <li><a href="http://target1.html">Link 1</a></li>
  <li><a href="http://target2.html">Link 2</a></li>
  <li><a href="http://target3.html">Link 3</a></li>
  <li><a href="http://target4.html">Link 4</a></li>
  </ul>

...

このコードの実装サンプル: ナビゲーションバーをリンクで切り替える

訳注: WAIC では SCR28-1 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: SCR28-1 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例 2

一連のウェブページのための目次はそれぞれのページの先頭近くで繰り返される。目次の先頭にあるボタンで、利用者はそれを消したり復元したりできる。

コード例:


...

   <script type="text/javascript">
  function toggle(id){
    var n = document.getElementById(id);
    n.style.display =  (n.style.display != 'none' ? 'none' : '' );
  }
  </script>

  ...

  <button onclick="return toggle('toc');">Toggle Table of Contents</button>
  <div id="toc">
    ...
  </div>

...

このコードの実装サンプル: 目次をボタンで切り替える

訳注: WAIC では SCR28-2 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: SCR28-2 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

参考リソース

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

検証

手順

ユーザインタフェースコントロールで、繰り返されるコンテンツを展開したり折りたたんだりできることを確認する。
コンテンツが展開されたとき、それが読み上げ順序の論理的な場所でプログラムによる解釈が可能なコンテンツに含まれていることを確認する。
コンテンツが折りたたまれているとき、それがプログラムによる解釈が可能でない部分にあることを確認する。

期待される結果

上記の全ての項目の結果が真である。

SCR29: 静的な HTML 要素にキーボードアクセシブルなアクションを追加する

適用 (対象)

HTML 及び XHTML、スクリプト

これは、次の達成基準に関連する達成方法である:

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

SCR29 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、 div や span などの静的な HTML 要素により実行されるユーザインターフェースコントロールにキーボードアクセスを提供する方法を示すことである。この達成方法は tabindex 属性を設定することで要素をフォーカス可能にし、onclick ハンドラに加えて onkeyup 又は onkeypress ハンドラを提供することでキーボードから動作を実行することができるようにするものである。

tabindex 属性の値が 0 の際、要素はキーボードでフォーカス可能であり、文書のタブ順序に含まれる。tabindex 属性の値が -1 の際、要素はタブ移動できないが、element.focus() を使用することによりフォーカスをプログラムで制御できる。

静的な HTML 要素にはそれらに関連した動作がないため、スクリプトが利用できない環境に対する、代替としての実装又は説明を提供することはできない。この達成方法はクライアントサイドスクリプティングが利用できる環境でのみ使用されるべきである。

注記: そのようなユーザインターフェースコントロールは SC 4.1.2 を達成しなければならない。ユーザインターフェースコントロールの役割、名前及び状態についての情報がないままこの達成基準を適用する場合、失敗例 F59 に該当し、スクリプトを用いて、HTML の div 要素又は span 要素をユーザインタフェースのコントロールにしたことによる達成基準 4.1.2 の失敗例となる。

事例

事例 1: div 要素に JavaScript によるアクションを追加する

ページにある div 要素には一意の id 属性及び値が 0 の tabindex 属性が付与されている。スクリプトはドキュメントオブジェクトモデル (DOM) を利用し、id によって div 要素を見つけ onclick ハンドラ及び onkeyup ハンドラを追加する。onkeyup ハンドラは Enter キーが押下された際、アクションを実行する。div 要素を見つけて変更するには、div 要素が DOM の中に読み込まれた状態でなければならないことに注意する。これは、通常、body 要素の onload イベントでスクリプトを呼び出すことで達成される。イベントハンドラを追加するスクリプトはユーザエージェントが JavaScript をサポートし、かつ有効にしている場合にのみ実行される。

コード例:


...
<script type="text/javascript">
 // これはアクションを実行する関数である。このシンプルな例はメッセージを開閉する。
 function doSomething(event) {
   var msg=document.getElementById("message");
   msg.style.display = msg.style.display=="none" ? "" : "none";
   // リンクのhref属性が実行されないよう、関数からfalseを返す
   return false;
 }
 // これは Enter キーが押された際にアクションが実行される関数である。
 function doSomethingOnEnter(event) {
   var key = 0;
   // window.event 又はイベントオブジェクトが使用されているかに応じて押されたキーを判定する。
   if (window.event) {
     key = window.event.keyCode;
   } else if (event) {
     key = event.keyCode;
   }
   // Enter キーが押されたか？
   if (key == 13) {
     return doSomething(event);
   } 
   // イベントが処理されなかったため、trueを返す
   return true;
 }
 // このsetUpActions()関数は存在するdiv要素にonclick及びonkeyupイベントハンドラを設定するために呼び出されなければならない。
 // この関数はid="active"の付与されたdiv要素がDOMに読み込まれた後に呼び出されなければならない。
 // この例では、setUpActions()関数はbody要素のonloadイベントから呼び出されている。
 function setUpActions() {
   // divオブジェクトを取得する
   var active=document.getElementById("active");
   // onclickハンドラをオブジェクトに割り当てる
   // 関数が返された後、href属性を止めるため、onclickハンドラからfalseを返すことが重要である
   active.onclick=doSomething;
   // onkeyupハンドラをオブジェクトに割り当てる
   active.onkeyup=doSomethingOnEnter;
 }
 </script>

 <body onload="setUpActions();">
 <p>Here is the link to modify with a javascript action:</p>
 <div>
  <span id="active" tabindex="0">Do Something</span>
 </div>
 <div id="message">Hello, world!</div>
...

このコードの実装例: JavaScriptによる制御を用いてdiv要素を作成する。

参考リソース

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

HTML 4.01 Scripts
HTML 4.01 Giving focus to an element
Accessible Rich Internet Applications (WAI-ARIA) Version 1.0 Global States and Properties
WAI-ARIA Primer, Provision of the keyboard or input focus
Document Object Model (DOM) Technical Reports
Internet Explorer, HTML and DHTML Reference, tabIndex Property

訳注 1: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記はそれぞれ、HTML 5.2§4.12. Scripting、HTML 5.2§5.4.3. The tabindex attribute を代わりに参照できる。

訳注 2: 「WAI-ARIA Primer, Provision of the keyboard or input focus」が挙げられているが、WAI-ARIA 1.0 Primer は作成が破棄されている。代わりに、WAI-ARIA Authoring Practices 1.1 §5. Developing a Keyboard Interface を参照できる。

訳注 3: DOM 仕様は現在、WHATWG で策定されている。DOM Standard も参照のこと。

訳注 4: MSDN のページ「Internet Explorer, HTML and DHTML Reference, tabIndex Property」が MDN にリダイレクトされているが、これは MSDN の文書が MDN に統合されたためである。このリダイレクト処理の詳細については、Microsoft Edge Dev Blog 及びマイナビニュースを参照されたい。

検証

手順

スクリプトをサポートするユーザエージェントで:

マウスを用い、コントロールをクリックする。
スクリプトのアクションが適切に実行されることを確認する。
キーボードでコントロールに移動して、フォーカスを与えることが可能であることを確認する。
キーボードのフォーカスをコントロールに設定する。
Enter キーを押すことで、スクリプトのアクションを呼び出すことを確認する。

期待される結果

手順全ての結果が真である。

SCR30: リンクテキストを変更するために、スクリプトを使用する

適用 (対象)

HTML 及び XHTML で使用されるクライアントサイドスクリプト

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、リンクが文脈以外でも理解可能になるように、追加情報をリンクテキストに加えることを利用者が選択できるようにすることである。

一部の利用者は、リンクの文脈を参照する必要がないように、リンクがすべてを含んでいることを好む。別の利用者は、それぞれのリンクに文脈に関する情報が含まれていると、反復されてサイトの使い勝手が低下すると感じている。支援技術の利用者の間では、どちらが好ましいかに関して、ワーキンググループへのフィードバックは分かれている。この達成方法は、利用者自身にとって良い方法を選ぶことを可能にする。

どのようなリンクの目的を理解する場合でも追加の文脈が必要とならないようにするため、そのページのリンクのリンクテキストを展開するページの先頭近くにリンクが提供される。展開されるリンクの目的がそのリンクテキストから、常に直接理解可能でなければならない。

この達成方法では、現在表示されているページのリンクだけを展開する。利用者がそのサイトに対して 1 度だけ設定を行えば良いようにするために、設定情報を Cookie 又はサーバーサイドのユーザプロファイルに保存することも可能であり、場合によってはそれが望ましい。

事例

事例 1

この例では、JavaScript を用いて直接リンクのテキストに文脈上の情報を追加する。link クラスはどのテキストを追加するかを決定する。「リンクを展開する」リンクが選択されたとき、ページ内のそれぞれのリンクにテキストを追加すべきかがテストされる。

コード例:


...
<script type="text/javascript">
var expanded = false;
var linkContext = {
	"hist":" version of The History of the Web",
	"cook":" version of Cooking for Nerds"
};

function doExpand() {
	var links = document.links;
	
	for (link of links) {
		var cn = link.className;
		if (linkContext[cn]) {
			span = link.appendChild(document.createElement("span"));
			span.setAttribute("class", "linkexpansion");
			span.appendChild(document.createTextNode(linkContext[cn]));
		}
	}
	objUpdate = document.getElementById('expand');
	if (objUpdate)
	{
		objUpdate.childNodes[0].nodeValue = "Collapse links";
	}
	expanded = true;
}

function doCollapse() {
	objUpdate = document.getElementById('expand');
	var spans = document.getElementsByTagName("span");
	var span;

	// リンク一式を戻り、文頭から削除することで配列の添え数を変更する
	// そして処理を乱す
	for (i = spans.length - 1; i >= 0; i--) {
		span = spans[i];
		if (span.getAttribute("class") == "linkexpansion")
			span.parentNode.removeChild(span);
	}
	if (objUpdate)
	{
		objUpdate.childNodes[0].nodeValue = "Expand links";
	}
	expanded = false;
}

function toggle() {
	if (expanded) doCollapse();
	else doExpand();
}
</script>

...

<h1>Books for download</h1>
<p><button id="expand" onclick="toggle();">Expand Links</button></p>
<ul>
	<li>The History of the Web: <a href="history.docx" class="hist">Word</a>, <a href="history.pdf" class="hist">PDF</a>, <a href="history.html" class="hist">HTML</a> </li>

	<li>Cooking for Nerds: <a href="history.docx" class="cook">Word</a>, <a href="history.pdf" class="cook">PDF</a>, <a href="history.html" class="cook">HTML</a> </li>
</ul>
...

このコードの実装サンプル: 要求に応じてリンクを展開する。

検証

手順

ページの先頭近くに、リンクを展開するリンクがあることを確認する
手順 1. で特定したリンクがリンクテキストだけで特定できることを確認する
リンクテキストだけで特定できないリンクをページ中から探す
手順 1. で特定したコントロールを有効にする
手順 3. で特定したリンクの目的が、リンクテキストだけで特定できることを確認する

期待される結果

1.、2. 及び 5. の結果が真である

SCR31: フォーカスのある要素の背景色又はボーダーを変更するために、スクリプトを使用する

適用 (対象)

HTML 及び XHTML、CSS、Script

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.7 (フォーカスの可視化)
- クイックリファレンス 2.4.7 (フォーカスの可視化)
- 達成基準 2.4.7 (フォーカスの可視化)を理解する

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

SCR31 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、コンテンツ制作者が CSS を適用してフォーカス表示を通常よりもより見やすくするために JavaScript を使えるようにすることである。要素がフォーカスを受ける時、背景色またはボーダーは視覚的に異なるように変化する。要素からフォーカスがはずれたとき元のスタイルにもどる。この達成方法は :focus 疑似クラスをサポートしているいないに関わらず、スクリプトや CSS をサポートしているどんな HTML のユーザエージェントでも用いることができる。

事例

事例 1

この事例において、リンクにフォーカスが当たった時、背景は黄色に変わる。フォーカスがはずれたとき、黄色ではなくなる。もしリンクに背景色がある場合は、スクリプト内で””よりむしろその色を用いることに注意する。

コード例:

...
<script>
 function toggleFocus(el)
 {
  el.style.backgroundColor =  el.style.backgroundColor=="yellow" ? "inherit" : "yellow";
 }
</script>

...

<a href="example.html" onfocus="toggleFocus(this)" onblur="toggleFocus(this)">focus me</a>
...

C15: ユーザインタフェースコンポーネントがフォーカスを受けとったときの提示を変更するために、CSS を使用する

検証

手順

ページ内の各要素にタブ移動する。
フォーカス表示が可視であることを確認する。

期待される結果

2.の結果が真である。

SCR32: クライアントサイドのバリデーションを提供し、DOM を介してエラーテキストを追加する

適用 (対象)

HTML 又は XHTML で使用されるスクリプト。

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、クライアントサイドでフォームフィールドの検証に失敗したときにエラーメッセージを表示する方法について説明することである。アンカー要素はリスト中でエラーメッセージを表示させる際に使用され、検証が必要なフィールドの上に挿入される。フォーカスをエラーメッセージの場所に移し、利用者の注意を引くために、アンカー要素がエラーメッセージに使用される。アンカー要素の href は、エラーがみつかったフィールドへのページ内リンクを含む。

配置されたアプリケーションにおいて、もし JavaScript が無効になっていれば、クライアントサイドの検証は行われない。そのため、この達成方法はスクリプトが適合性において信頼できる、又はサーバーサイドの検証技術があらゆるエラーを発見し、エラーを含むフィールドの情報とともにページを返すように用いられている場合のみ、十分であるといえる。

訳注: WAIC では SCR32 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: SCR32 では、「達成可能」と評価されている。WAIC はこの達成方法が検証した環境で広く動作すると判断している。

事例

事例 1

この事例は必須のフィールドを検証し、さらに特定の書式が必要なフィールドを検証する。エラーがみつかったとき、スクリプトはエラーメッセージの一覧を DOM に挿入し、フォーカスをそこへ移動する。

サンプルの画面イメージ: スクリーンショットは、正しく記入が行われていないいくつかのフィールドのエラーメッセージをあらわしている。エラーメッセージはリンクリストでフォームの先頭近くに現れる。

HTML 及び Javascript のコード

これは事例のフォームの HTML である:

コード例:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
    <head>
        <title>Form Validation</title>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
        <link href="css/validate.css" rel="stylesheet" type="text/css"/>
        <script type="text/javascript" src="scripts/validate.js"/>
    </head>
    <body>

        <h1>Form Validation</h1>

        <p>The following form is validated before being submitted if scripting is available,
            otherwise the form is validated on the server. All fields are required, except those
            marked optional. If errors are found in the submission, the form is cancelled and 
            a list of errors is displayed at the top of the form.</p>

        <p> Please enter your details below. </p>

        <h2>Validating Form</h2>

        <form id="personalform" method="post" action="index.php">
            <div class="validationerrors"/>
            <fieldset>
                <legend>Personal Details</legend>
                <p>
                    <label for="forename">Please enter your forename</label>
                    <input type="text" size="20" name="forename" id="forename" class="string"
                        value=""/>
                </p>
                <p>
                    <label for="age">Please enter your age</label>
                    <input type="text" size="20" name="age" id="age" class="number" value=""/>
                </p>
                <p>
                    <label for="email">Please enter your email address</label>
                    <input type="text" size="20" name="email" id="email" class="email" value=""/>
                </p>
            </fieldset>
            <p>
                <input type="submit" name="signup" value="Sign up"/>
            </p>
        </form>
        <h2>Second Form</h2>
        <form id="secondform" method="post" action="index.php#focuspoint">
            <div class="validationerrors"/>
            <fieldset>
                <legend>Second Form Details</legend>
                <p>
                    <label for="suggestion">Enter a suggestion</label>
                    <input type="text" size="20" name="suggestion" id="suggestion" 
                      class="string" value=""/>
                </p>
                <p>
                    <label for="optemail">Please enter your email address (optional)</label>
                    <input type="text" size="20" name="optemail" id="optemail"
                        class="optional email" value=""/>
                </p>
                <p>
                    <label for="rating">Please rate this suggestion</label>
                    <input type="text" size="20" name="rating" id="rating" 
                      class="number" value=""/>
                </p>
                <p>
                    <label for="jibberish">Enter some jibberish (optional)</label>
                    <input type="text" size="20" name="jibberish" id="jibberish" value=""/>
                </p>

            </fieldset>
            <p>
                <input type="submit" name="submit" value="Add Suggestion"/>
            </p>
        </form>
    </body>
</html>

以下は検証を行ってエラーメッセージを挿入する JavaScript である:

コード例:


window.onload = initialise;

function initialise()
{
   var objForms = document.getElementsByTagName('form');
   var iCounter;

   // フォームそれぞれにイベントハンドラを追加
   for (iCounter=0; iCounter<objForms.length; iCounter++)
   {
      objForms[iCounter].onsubmit = function(){return validateForm(this);};
   }
}


// フォームのイベントハンドラ
function validateForm(objForm)
{
   var arClass = [];
   var iErrors = 0;
   var objField = objForm.getElementsByTagName('input');
   var objLabel = objForm.getElementsByTagName('label');
   var objList = document.createElement('ol');
   var objError, objExisting, objNew, objTitle, objParagraph, objAnchor, objPosition;
   var strLinkID, iFieldCounter, iClassCounter, iCounter;

   // 部分識別子を固有にするため、
   // フォームのid又はnameを取得する
   if (objForm.id)
   {
      strLinkID = objForm.id + 'ErrorID';
   }
   else
   {
      strLinkID = objForm.name + 'ErrorID';
   }

   // validationクラスを探索するため、inputフォームコントロールをループする
   for (iFieldCounter=0; iFieldCounter<objField.length; iFieldCounter++)
   {
      // フィールドのクラスを取得し、適切なクラスを探す
      arClass = objField[iFieldCounter].className.split(' ');
      for (iClassCounter=0; iClassCounter<arClass.length; iClassCounter++)
      {
         switch (arClass[iClassCounter])
         {
            case 'string':
               if (!isString(objField[iFieldCounter].value, arClass))
               {
                  if (iErrors === 0)
                  {
                     logError(objField[iFieldCounter], objLabel, objList, strLinkID);
                  }
                  else
                  {
                     logError(objField[iFieldCounter], objLabel, objList, '');
                  }
                  iErrors++;
               }
               break;
            case 'number':
               if (!isNumber(objField[iFieldCounter].value, arClass))
               {
                  if (iErrors === 0)
                  {
                     logError(objField[iFieldCounter], objLabel, objList, strLinkID);
                  }
                  else
                  {
                     logError(objField[iFieldCounter], objLabel, objList, '');
                  }
                  iErrors++;
               }
               break;

            case 'email' :
               if (!isEmail(objField[iFieldCounter].value, arClass))
               {
                  if (iErrors === 0)
                  {
                     logError(objField[iFieldCounter], objLabel, objList, strLinkID);
                  }
                  else
                  {
                     logError(objField[iFieldCounter], objLabel, objList, '');
                  }
                  iErrors++;
               }
               break;
         }
      }
   }

   if (iErrors > 0)
   {
      // validではない場合、エラーメッセージを表示する
      objError = objForm.getElementsByTagName('div');
      
      // 存在しているエラーを探す
      for (iCounter=0; iCounter<objError.length; iCounter++)
      {
         if (objError[iCounter].className == 'validationerrors')
         {
            objExisting = objError[iCounter];
         }
      }

      objNew = document.createElement('div');
      objTitle = document.createElement('h2');
      objParagraph = document.createElement('p');
      objAnchor = document.createElement('a');

      if (iErrors == 1)
      {
         objAnchor.appendChild(document.createTextNode('1 Error in Submission'));
      }
      else
      {
         objAnchor.appendChild(document.createTextNode(iErrors + ' Errors in Submission'));
      }
      objAnchor.href = '#' + strLinkID;
      objAnchor.className = 'submissionerror';

      objTitle.appendChild(objAnchor);
      objParagraph.appendChild(document.createTextNode('Please review the following'));

      objNew.className = 'validationerrors';

      objNew.appendChild(objTitle);
      objNew.appendChild(objParagraph);
      objNew.appendChild(objList);
      
      // 既にエラーがある場合、新しいエラーと交換する。
      // それ以外の場合、フォームの先頭に新しいエラーを追加する。
      if (objExisting)
      {
         objExisting.parentNode.replaceChild(objNew, objExisting);
      }
      else
      {
         objPosition = objForm.firstChild;
         objForm.insertBefore(objNew, objPosition);
      }

      // 待ち時間の設定
      setTimeout(function() { objAnchor.focus(); }, 50);
      
      // フォームを送信しない
      objForm.submitAllowed = false;
      return false;
   }

   // フォームを送信
   return true;
}

// 問題のあるフィールドコントロールを指すリスト項目にリンクを追加する関数
function addError(objList, strError, strID, strErrorID)
{
   var objListItem = document.createElement('li');
   var objAnchor = document.createElement('a');
   
   // フォームコントロールへの部分識別子
   objAnchor.href='#' + strID;

   // エラーの見出しに向けたターゲットにする
   if (strErrorID.length > 0)
   {
      objAnchor.id = strErrorID;
   }

   // エラーメッセージ用のラベルプロンプトを使う
   objAnchor.appendChild(document.createTextNode(strError));
   // フォームコントロールにフォーカスを当てるために、キーボード及びマウスイベントを追加する
   objAnchor.onclick = function(event){return focusFormField(this, event);};
   objAnchor.onkeypress = function(event){return focusFormField(this, event);};
   objListItem.appendChild(objAnchor);
   objList.appendChild(objListItem);
}

function focusFormField(objAnchor, objEvent)
{
   var strFormField, objForm;

   // キーボードでもリンクが機能するようにする
   if (objEvent &amp;&amp; objEvent.type == 'keypress')
   {
      if (objEvent.keyCode != 13 &amp;&amp; objEvent.keyCode != 32)
      {
         return true;
      }
   }

   // フォームコントロールにフォーカスを当てる
   strFormField = objAnchor.href.match(/[^#]\w*$/);
   objForm = getForm(strFormField);
   objForm[strFormField].focus();
   return false;
}

// 与えられたフォームフィールドの名前から、フォーム要素を返す関数
function getForm(strField)
{
   var objElement = document.getElementById(strField);

   // 適切なフォームを探す
   do
   {
      objElement = objElement.parentNode;
   } while (!objElement.tagName.match(/form/i) &amp;&amp; objElement.parentNode);

   return objElement;
}

// リスト中のエラーを記録する関数
function logError(objField, objLabel, objList, strErrorID)
{
   var iCounter, strError;

   // エラープロンプトのラベルを探す
   for (iCounter=0; iCounter<objLabel.length; iCounter++)
   {
      if (objLabel[iCounter].htmlFor == objField.id)
      {
         strError = objLabel[iCounter].firstChild.nodeValue;
      }
   }

   addError(objList, strError, objField.id, strErrorID);
}

// 検証ルーティン - 要求事項として

function isString(strValue, arClass)
{
   var bValid = (typeof strValue == 'string' &amp;&amp; strValue.replace(/^\s*|\s*$/g, '') 
     !== '' &amp;&amp; isNaN(strValue));

   return checkOptional(bValid, strValue, arClass);
}

function isEmail(strValue, arClass)
{
   var objRE = /^[\w-\.\']{1,}\@([\da-zA-Z\-]{1,}\.){1,}[\da-zA-Z\-]{2,}$/;
   var bValid = objRE.test(strValue);

   return checkOptional(bValid, strValue, arClass);
}

function isNumber(strValue, arClass)
{
   var bValid = (!isNaN(strValue) &amp;&amp; strValue.replace(/^\s*|\s*$/g, '') !== '');

   return checkOptional(bValid, strValue, arClass);
}

function checkOptional(bValid, strValue, arClass)
{
   var bOptional = false;
   var iCounter;

   // optionalについて確認
   for (iCounter=0; iCounter<arClass.length; iCounter++)
   {
      if (arClass[iCounter] == 'optional')
      {
         bOptional = true;
      }
   }

   if (bOptional &amp;&amp; strValue.replace(/^\s*|\s*$/g, '') === '')
   {
      return true;
   }

   return bValid;
   }

このコードの実装サンプルは、PHP、JavaScript、CSS 及び XHTML で実装されている: フォーム検証の例

検証

手順

アンカータグを用いてエラーメッセージを作成し、上記の達成方法による適切なスクリプトを使用する。

ページを読み込む。
エラーメッセージに関連付けられたフィールドに有効な値を入力し、エラーメッセージが表示されないことを確認する。
エラーメッセージに関連付けられたフィールドに無効な値を入力し、そのフィールドに正確なエラーメッセージが表示されることを確認する。
エラーメッセージがフォーカスを受け取ることを確認する。
表示されたエラーメッセージと関連付けられたフィールドに有効な値を入力し、エラーメッセージが除去されることを確認する。
アンカータグによって作例されたエラーメッセージと関連付けられた全てのフィールドに対して、繰り返す。

注記: 上記の手順を、支援技術を用いて実行することも推奨する。

期待される結果

2.、3.、4. 及び 5. の全ての結果が真である。

SCR33: コンテンツをスクロールし、かつそれを一時停止するメカニズムを提供するためにスクリプトを使用する

適用 (対象)

スクリプトでコントロールされる、コンテンツのスクロールをサポートするウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、スクロールするコンテンツがスクリプトで作成されている場合に、利用者にそのスクロールを停止する手段を提供することである。スクロールするコンテンツは、ロービジョンや認知障害の利用者にとって読みにくかったり、全く読めなかったりする。また、動くものは、一部の人々にとって、ウェブページのほかの部分に集中することへの妨げとなる。

事例

事例 1

この例では、CSS 及び JavaScript を用いて、いくつかのテキストを視覚的にスクロールさせている。スクロールの移動を停止するためのリンクが含まれている。

この方法では、JavaScript 又は CSS がサポートされていないか有効になっていないときは、すべてのテキストを表示し、リンクを省略する。

下のコードは、webSemantic によるアクセシブルなスクローラー (2008 年 7 月) の修正版である。

XHTML 部分:

コード例:

...
<div id="scroller">
<p id="tag">This text will scroll and a Pause/Scroll link will be present 
when Javascript and CSS are supported and active.</p>
</div>
...

CSS部分:

コード例:

...
body {font:1em verdana,sans-serif; color:#000; margin:0}

/* position:relative及びoverflow:hiddenは必須 */
#scroller { position:relative; overflow:hidden; width:15em; border:1px solid #008080; }

/* スクロールするテキスト用のフォーマットを追加 */
#tag { margin:2px 0; }

/* #testPは#tagのテキスト変更に関するプロパティを全て含む */
#testP { visibility:hidden; position:absolute; white-space:nowrap; } 

/* ページ先頭の目印として利用され、かつ幅を制限する */
#top { width:350px; margin:auto; }
...

JavaScript 部分:

コード例:


var speed=50        // スクロール速度
var step=3          // 動きのスムーズ度合い
var StartActionText= "Scroll"  // 開始させるリンクのテキスト
var StopActionText = "Pause"   // 停止させるリンクのテキスト

var x, scroll, divW, sText=""

function onclickIE(idAttr,handler,call){
  if ((document.all)&amp;&amp;(document.getElementById)){idAttr[handler]="Javascript:"+call}
}

function addLink(id,call,txt){
  var e=document.createElement('a')
  e.setAttribute('href',call)
  var linktext=document.createTextNode(txt)
  e.appendChild(linktext)
  document.getElementById(id).appendChild(e)
}

function getElementStyle() {
    var elem = document.getElementById('scroller');
    if (elem.currentStyle) {
        return elem.currentStyle.overflow;
    } else if (window.getComputedStyle) {
        var compStyle = window.getComputedStyle(elem, '');
        return compStyle.getPropertyValue("overflow");
    }
    return "";
}

function addControls(){
// 最初にCSSサポートをテスト
// style要素又は外部ファイルで定義されたoverflowプロパティ値をテスト
if (getElementStyle()=="hidden") {
  var f=document.createElement('div');
  f.setAttribute('id','controls');
  document.getElementById('scroller').parentNode.appendChild(f);
  addLink('controls','Javascript:clickAction(0)',StopActionText);
  onclickIE(document.getElementById('controls').childNodes[0],"href",'clickAction(0)');
  document.getElementById('controls').style.display='block';
  }
}

function stopScroller(){clearTimeout(scroll)}

function setAction(callvalue,txt){
  var c=document.getElementById('controls')
  c.childNodes[0].setAttribute('href','Javascript:clickAction('+callvalue+')')
  onclickIE(document.getElementById('controls').childNodes[0],"href",'clickAction

('+callvalue+')')
  c.childNodes[0].firstChild.nodeValue=txt
}

function clickAction(no){
  switch(no) {
    case 0:
      stopScroller();
      setAction(1,StartActionText);
      break;
    case 1:
      startScroller();
      setAction(0,StopActionText);
  }
}

function startScroller(){
  document.getElementById('tag').style.whiteSpace='nowrap'
  var p=document.createElement('p')
  p.id='testP'
  p.style.fontSize='25%' //mozilla向け修正 使用する前に4倍する
  x-=step
  if (document.getElementById('tag').className) p.className=document.getElementById

('tag').className
  p.appendChild(document.createTextNode(sText))
  document.body.appendChild(p)
  pw=p.offsetWidth
  document.body.removeChild(p)
  if (x<(pw*4)*-1){x=divW}
  document.getElementById('tag').style.left=x+'px'
  scroll=setTimeout('startScroller()',speed)
}

function initScroller(){
  if (document.getElementById &amp;&amp; document.createElement &amp;&amp; document.body.appendChild) {
    addControls();
    divW=document.getElementById('scroller').offsetWidth;
    x=divW;
    document.getElementById('tag').style.position='relative';
    document.getElementById('tag').style.left=divW+'px';
    var ss=document.getElementById('tag').childNodes;
    for (i=0;i<ss.length;i++) {sText+=ss[i].nodeValue+" "};
    scroll=setTimeout('startScroller()',speed);
  }
}

function addLoadEvent(func) {
  if (!document.getElementById | !document.getElementsByTagName) return
  var oldonload = window.onload
  if (typeof window.onload != 'function') {
    window.onload = func;
  } else {
    window.onload = function() {
      oldonload()
      func()
    }
  }
}

addLoadEvent(initScroller)

このコードの実装サンプル: コンテンツのスクロールにスクリプトを用い、停止する仕組みを提供しているサンプル

参考リソース

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

webSemantics Accessible Scroller

G4: コンテンツを一時停止させて、一時停止させたところから再開できるようにする

検証

手順

スクロールするコンテンツを一時停止するメカニズムが提供されていることを確認する。
一時停止するメカニズムを用いて、コンテンツのスクロールを一時停止する。
スクロールが停止し、自動的に再起動しないことを確認する。
一時停止中のコンテンツを再起動できるメカニズムが提供されていることを確認する。
提供されている再起動のメカニズムを用いて、コンテンツのスクロールを再起動する。
停止していた位置からスクロールが再開されることを確認する。

期待される結果

3. 及び 6. の結果が真である。

SCR34: テキストサイズに応じて拡大縮小するように、サイズ及びポジションを定める

適用 (対象)

クライアントサイドスクリプティング

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.4 (テキストのサイズ変更)
- クイックリファレンス 1.4.4 (テキストのサイズ変更)
- 達成基準 1.4.4 (テキストのサイズ変更)を理解する
注記: この達成方法は、達成基準 1.4.4 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.4.4 を理解するを参照すること。
達成基準 1.4.8 (視覚的提示)
- クイックリファレンス 1.4.8 (視覚的提示)
- 達成基準 1.4.8 (視覚的提示)を理解する
注記: この達成方法は、達成基準 1.4.8 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.4.8 を理解するを参照すること。

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

SCR34 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、文字サイズが拡大縮小されるのに従って、適切に拡大縮小する方法で要素のサイズ及びポジションを計算することである。

ここに要素のサイズとポジションを決める JavaScript の四つのプロパティがある:

offsetHeight (ピクセルでの要素の高さ)
offsetWidth (ピクセルでの要素の幅)
offsetLeft (ピクセルでの親要素 (offsetParent) の左からの距離)
offsetTop (ピクセルでの親要素 (offsetParent) の上からの距離)

offsetHeight や offsetWidth を用いて高さや幅を定めることは簡単である、しかし、オブジェクトの左とトップの位置を絶対配置の値として定める時、親要素を考える必要がある。下記において、calculatePosition 関数は、要素におけるすべての親ノードの最終的な値が決定するまで繰り返されている。その関数は objElement (当該の要素の名前) とオフセットプロパティ (offsetLeft 又は offsetTop ) の二つの引数を取っている。

事例

事例 1

Javascript の関数:

コード例:


function calculatePosition(objElement, strOffset)
{
    var iOffset = 0;

    if (objElement.offsetParent)
    {
        do 
        {
            iOffset += objElement[strOffset];
            objElement = objElement.offsetParent;
        } while (objElement);
    }

    return iOffset;
}

次の事例は、上の関数がオブジェクトを、参照オブジェクトの下、かつ、左から同じ距離に配置するために用いられていることを示している:

コード例:


// Get a reference object
var objReference = document.getElementById('refobject');
// Get the object to be aligned
var objAlign = document.getElementById('lineup');

objAlign.style.position = 'absolute';
objAlign.style.left = calculatePosition(objReference, 'offsetLeft') + 'px';
objAlign.style.top = calculatePosition(objReference, 'offsetTop') + objReference.offsetHeight + 'px';

参考リソース

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

MSDN: Fix the Box Instead of Thinking Outside It

訳注: 「MSDN: Fix the Box Instead of Thinking Outside It」はリソースがリダイレクトされているが適切に処理されていない。代わりに、MDN の HTMLElement.offsetHeight、HTMLElement.offsetWidth、HTMLElement.offsetLeft、HTMLElement.offsetTop をそれぞれ参照できる。

検証

手順

テキストサイズの変更とともにテキストコンテナのサイズを調整するように設計されているページを開く。
ブラウザのテキストサイズ調節を使って 200% のサイズまで大きくする。(ズーム機能は使用しない)
テキストコンテナのサイズがテキストサイズに合わせて調整されることを確認する。
テキストサイズを大きくした結果、どのテキストも「切り取られ」たり、見えなくなっていたりしないことを確認する。

期待される結果

3.及び 4.の結果が真である。

SCR35: アンカー及びボタンの onclick イベントを用いて、アクションをキーボード操作可能にする

適用 (対象)

HTML 又は XHTML で使用されるスクリプト。

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、キーボードでアクセス可能なコントロールに加えることで、キーボードでアクセス可能になるスクリプトの関数を呼び出す方法について説明することである。スクリプトによる動きが確実にキーボードから呼び出されるように、それらの動きは「ネイティブに実行可能な」HTML 要素 (リンク及びボタン) に関連付けられている。これらの要素の onclick イベントは機器に依存していない。「onclick」という表現はマウスに関連付けられているようにも思えるが、onclick イベントは実際のところ、リンク又はボタンのデフォルトの動きにマッピングされている。デフォルトの動きは、利用者がマウスで要素をクリックしたときに発生するが、要素にフォーカスして Enter キーやスペースキーを押したとき及び、他のアクセシビリティ API によってトリガーされたときにも発生する。

この達成方法はクライアントサイドスクリプトに依存しているが、スクリプトが利用できない環境に対する、代替としての実装又は説明として意味がある。アンカー要素を使って JavaScript によるアクションを呼び出すとき、代替としての実装又は説明は href 属性によって提供される。ボタンを使用するときは、フォームの送信によって提供される。

事例

事例 1

スクリプトを実行するリンクで、スクリプトをサポートしていないブラウザに対して代替手段を持たないもの。この方法は、スクリプトがアクセシビリティサポーテッドな技術に依存しているときのみに使用されるべきである。

このリンクからナビゲートしたくないのではあるが、これを実際のリンクにし、適切なイベントを得るために、a 要素上の href 属性を使わなければならない。この事例では、我々は「#」をリンクターゲットとして使用しているが、何を使用しても良い。このリンクからナビゲートされることはない。

doStuff() イベントハンドリング関数の最後にある「return false;」は、ブラウザにその URI へ移動しないよう指示している。それがなければ、ページはスクリプト実行後に再読み込みされることになる。

コード例:


<script> 
function doStuff()
 {
  //do stuff
    return false;
  }
</script>
<a href="#" onclick="return doStuff();">do stuff</a>

事例 2

スクリプトを実行するリンクであるが、スクリプトが実行可能でなければ他のページに移動させるもの。この方法はスクリプトに依存しないサイトで、移動先がスクリプトと同じ機能を提供している場合にのみ使用される。この例は、href が実在するページである dostuff.htm に設定されていること以外は、事例 1と同じである。dostuff.htmでは、スクリプトと同じ機能を提供しなければならない。doStuff() イベントハンドリング関数の最後にある「return false;」が、ブラウザにその URI へ移動しないように指示している。そうでなければ、ブラウザはスクリプト実行後に dostuff.htm に移動してしまう。

コード例:


<script> 
function doStuff() 
 {  
  //do stuff  
  return false; 
 }
</script>
<a href="dostuff.htm" onclick="return doStuff();">do stuff</a>

このコードの実装サンプル: JavaScriptを用いてアクションリンクを作成

事例 3

スクリプトを実行して、かつスクリプトを使わない利用者のためにフォーム送信を代替とするボタン。このアプローチは、スクリプトに依存しないサイトで、フォームの送信がスクリプトと同じ機能を提供できる場合にのみ使用できる。onsubmit="return false;" はフォームから送信されるのを防ぐ。

コード例:


<script>
  function doStuff()
 {
     //do stuff
 }
</script>
<form action="doStuff.aspx" onsubmit="return false;">
 <input type="submit" value="Do Stuff" onclick="doStuff();" />
</form>

このコードの実装サンプル: JavaScript を用いてアクションボタンを作成

事例 4

スクリプトを実行するボタンで、input type="image" を用いて実装されているもの。input には、画像と等価のテキストを提供するために、タイトル属性を追加しなければならないことに注意する。この方法は、スクリプトに依存しているときのみに利用すべきである。

コード例:


<script>
  function doStuff()
  {
     //do stuff
   return false;
  }
</script>
<input type="image" src="stuff.gif" title="Do stuff" onclick="return doStuff();" />

事例 5

スクリプトを実行するボタンで、input type="submit"、input type="reset" 又は input type="button" のいずれかを用いて実装されているもの。この方法は、スクリプトに依存しているときのみに利用すべきである。

コード例:


<input type="submit" onclick="return doStuff();" value="Do Stuff" />

事例 6

スクリプトを実行するボタンで、button…/button を用いて実装されているもの。これは、ボタンの見た目をより詳細に調整したいときに有効である。この特定の例では、ボタンはアイコンとテキストの両方を含んでいる。この方法は、スクリプトに依存しているときのみに利用すべきである。

コード例:


<button onclick="return doStuff();">
 <img src="stuff.gif" alt="stuff icon">
 Do Stuff
</button>

参考リソース

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

訳注 1: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記はそれぞれ、HTML 5.2§4.12. Scripting、HTML 5.2§4.10. Forms、HTML 5.2§4.8. Linksを代わりに参照できる。

訳注 2: DOM 仕様は現在、WHATWG で策定されている。DOM Standard も参照のこと。

検証

手順

a、button、又は input 要素と関連付けられたすべてのスクリプトのアクションについて:

スクリプトをサポートするユーザエージェントで:
- マウスを用い、コントロールをクリックする。
- スクリプトのアクションが適切に実行されることを確認する。
- コントロールがアンカー要素である場合、アンカー要素の href 属性の URI が呼び出されないことを確認する。
- キーボードでコントロールに移動して、フォーカスを与えることが可能であることを確認する。
- キーボードのフォーカスをコントロールに設定する。
- Enter キーを押すことで、スクリプトのアクションを呼び出すことを確認する。
- コントロールがアンカー要素である場合、アンカー要素の href 属性の URI が呼び出されないことを確認する。
スクリプトをサポートしていないユーザエージェントで:
- マウスでコントロールをクリックする。
- コントロールがアンカー要素である場合、アンカー要素の href 属性の URI が呼び出されることを確認する。
- キーボードでコントロールに移動して、フォーカスを与えることが可能であることを確認する。
- キーボードのフォーカスをコントロールに設定する。
- コントロールがアンカー要素である場合、Enter キーを押すことでアンカー要素の href 属性の URI が呼び出されることを確認する。

期待される結果

上記の手順全ての結果が真である。

SCR36: 静的なウィンドウ又は領域にある、動きのあるテキスト、スクロールするテキスト、又は自動更新されるテキストを利用者が表示できるメカニズムを提供する

適用 (対象)

動く、点滅する、又はテキストを更新し、静的なテキストブロックを生成する全てのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.1 (タイミング調整可能)
- クイックリファレンス 2.2.1 (タイミング調整可能)
- 達成基準 2.2.1 (タイミング調整可能)を理解する

解説

スペースが限られているために、スクロールするテキストを表示するウェブページがある。小さなテキストウィンドウの中でテキストをスクロールさせることにより、その速度にあわせて読むことができる利用者にはコンテンツが利用可能となるが、それよりも速度が読むのが遅い利用者や、支援技術の利用者にとっては問題となる。この達成方法では、動きを止めて、テキストブロック全体を静的に利用可能にするメカニズムを提供する。テキストは別ウィンドウかページ中の (より大きな) セクションで利用可能になるだろう。そうすることで、利用者はテキストを自分の速度で読むことができる。

この達成方法は、動いているテキストが全て同時に画面に表示できない場合 (例: 長いチャットでの会話) には適用されない。

注記: この達成方法は、不適合のコンテンツのための適合している代替版のページを表示するためのスタイルスイッチの達成方法とあわせて利用できる。詳細については、C29: 適合している代替版を提供するために、スタイルスイッチャーを使用する (CSS) 及び適合している代替版を理解するを参照のこと。

事例

事例 1: スクロールするテキストを展開する

大きなテキストブロックがページ中の小さなマーキーの範囲をスクロールする。ボタンにより、利用者はスクロールを止め、テキストブロック全体を表示することができる。

注記: このコード例では CSS と JavaScript の両方が利用可能で有効になっている必要がある。

CSS 部分:

コード例:


#scrollContainer {
        visibility: visible;
        overflow: hidden;
        top: 50px; left: 10px;
        background-color: darkblue;
      }
      .scrolling {
        position: absolute;
        width: 200px;
        height: 50px;
      }
      .notscrolling {
        width: 500px;
        margin:10px;
      }
      #scrollingText {
        top: 0px;
        color: white;
      }
      .scrolling #scrollingText {
        position: absolute;
      }
      </a>

スクリプト及び HTML コンテンツ:

コード例:

<script type="text/javascript">

      var tid;
      function init() {
        var st = document.getElementById('scrollingText');
        st.style.top = '0px';
        initScrolling();
      }
      function initScrolling () {
        tid = setInterval('scrollText()', 300);
      }
      function scrollText () {
        var st = document.getElementById('scrollingText');
        if (parseInt(st.style.top) > (st.offsetHeight*(-1) + 8)) {
          st.style.top = (parseInt(st.style.top) - 5) + 'px';
        } else {
          var sc = document.getElementById('scrollContainer');
          st.style.top = parseInt(sc.offsetHeight) + 8 + 'px';
        }
      }
      function toggle() {
        var scr = document.getElementById('scrollContainer');
        if (scr.className == 'scrolling') {
          scr.className = 'notscrolling';
          clearInterval(tid);
           document.getElementById('scrollButton').value="Shrink";
        } else {
          scr.className = 'scrolling';
          initScrolling();
          document.getElementById('scrollButton').value="Expand";
        }
      }
  <input type="button" id="scrollButton" value="Expand" onclick="toggle()" />
  <div id="scrollContainer" class="scrolling">
    <div id="scrollingText" class="on">
    .... Text to be scrolled ...
    </div>
  </div>
...

このコードの実装サンプル: スクロールするテキストを展開

検証

この達成方法に利用可能な検証はない。

SCR37: デバイス非依存な方法でカスタムダイアログを作成する

適用 (対象)

スクリプトで使用される HTML 及び XHTML

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.3 (フォーカス順序)
- クイックリファレンス 2.4.3 (フォーカス順序)
- 達成基準 2.4.3 (フォーカス順序)を理解する

解説

コンテンツ制作者はしばしば、ブラウザによって提供されるポップアップウインドウを使わずに、独自のダイアログを作成したがる。これは通常、ダイアログのコンテンツを div の中に収めて、その div をコンテンツの上に CSS による重なり順及び絶対配置を用いて配置するというやり方でおこなわれる。

これらのダイアログをアクセシブルにするには、いくつかの簡単なルールに従う必要がある。

リンクやボタンの onclick イベントからダイアログを起動するスクリプトをトリガーにする。
ダイアログの div を Document Object Model (DOM) の中、トリガーした要素の直後に配置する。トリガーした要素がフォーカスを保持し、ダイアログのコンテンツをその要素のあとに挿入することで、ダイアログの中のコンテンツがスクリーンリーダーの読み上げ順序で次になり、タブ順序も次になる。それでも、ダイアログは視覚的にページ上のあらゆる場所に絶対配置できる。これは、下の例のようにダイアログを HTML の中で作成し、CSS で非表示にする方法又は、トリガーした要素の直後にスクリプトで挿入する方法のどちらでも実装できる。
ダイアログの div 内部の HTML が、その他のコンテンツと同じアクセシビリティガイドラインの要件を満たしていることを保証する。

リンクがダイアログを開閉できたり、キーボードのフォーカスが外れるとダイアログが閉じるようにしたりすることはすばらしいが、必ずしも必要なわけではない。

訳注: WAIC では SCR37 に関するアクセシビリティ・サポーテッド（AS）情報を提供している。

2014 年 6 月版のアクセシビリティ・サポーテッド（AS）情報: SCR37 では、「要注意」と評価されている。WAIC はウェブ制作者にこの達成方法が一部の環境では動作しないことに注意を促すものである。

事例

事例 1: ダイアログを開くオプションボタン

この例の HTML には、トリガーとなる要素、この場合はボタンとダイアログのフレームとして機能する div がある。

トリガーとなる要素はボタンで、スクリプトは onclick イベントのトリガーである。これは適切なイベントをオペレーティングシステムに送るので、支援技術は DOM の中の変化に気がつくことができる。

この例では、ダイアログ内の送信及びリセットボタンは単純に div に隠れている。

コード例:

...
<button onclick="TogglePopup(event,true)"
	name="pop0001">Options</button>
<div class="popover" id="pop0001">
  <h3>Edit Sort Information</h3>
  <form action="default.htm" onsubmit="this.parentNode.style.display='none'; return false;" onreset="this.parentNode.style.display='none'; return false;">
    <fieldset>
      <legend>Sort Order</legend> 
      <input type="radio" name="order" id="order_alpha" /><label for="order_alpha">Alphabetical</label>
      <input type="radio" name="order" id="order_default" checked="true" /><label for="order_default">Default</label>
    </fieldset>
<div class="buttons">
  <input type="submit" value="OK" />
  <input type="reset" value="Cancel" />
</div>
</form>
</div>
...

div、見出し、及び form 要素は CSS でダイアログに見えるようにスタイル付けされている。

コード例:

...
a { color:blue; }
a.clickPopup img { border:none; width:0; }

div.popover { position:absolute; display:none; border:1px outset; background-color:beige; font-size:80%; background-color:#eeeeee; color:black; }
div.popover h3 { margin:0; padding:0.1em 0.5em; background-color:navy; color:white; }
#pop0001 { width:20em; }
#pop0001 form { margin:0; padding:0.5em; }
#pop0001 fieldset { margin-bottom:0.3em; padding-bottom:0.5em; }
#pop0001 input, #pop0001 label { vertical-align:middle; }
#pop0001 div.buttons { text-align:right; }
#pop0001 div.buttons input { width:6em; }
...

スクリプトはポップアップする div の表示を切り替え、表示させたり隠したりする。

コード例:

...
function TogglePopup(evt,show)
{
	HarmonizeEvent(evt);
	var src = evt.target;
	if ("click" == evt.type)
	{
		evt.returnValue = false;
	}
	var popID = src.getAttribute("name");
	if (popID)
	{
		var popup = document.getElementById(popID);
		if (popup)
		{
			if (true == show)
			{
				popup.style.display = "block";
			}
			else if (false == show)
			{
				popup.style.display = "none";
			}
			else
			{
				popup.style.display = "block" == popup.style.display ? "none" : "block";
			}
			if ("block" == popup.style.display)
			{
				//window.alert(document.documentElement.scrollHeight);
				popup.style.top = ((document.documentElement.offsetHeight - popup.offsetHeight) / 2 ) + 'px';
				popup.style.left = ((document.documentElement.offsetWidth - popup.offsetWidth) / 2) + 'px';
			}
		}
	}
}

function SubmitForm(elem)
{ 
	elem.parentNode.style.display='none'; 
	return false;
}

function ResetForm(elem)
{ 
	elem.parentNode.style.display='none'; 
	return false;
}
...

このコードの実装サンプル: ダイアログを開くオプションボタン

参考リソース

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

Microsoft Developer Network Whitepaper: Writing Accessible Web Applications by Cynthia C. Shelly and George Young. (Microsoft Word Format)
Microsoft Active Accessibility 2.0 SDK. Includes Inspect32.exe and other MSAA tools.
Instructions for the Inspect tool
Using the Inspect tool to find name Name, Role and Value for Javascript
Microsoft Internet Explorer Developer Toolbar.. Allows examination of script-generated DOM in Microsoft Internet Explorer
Firebug. Allows examination of script-generated DOM in Firefox.

訳注 2: Firefox のアドオン「Firebug」は開発が終了している。代わりに開発ツールを使用できる。開発ツール | MDN も参照のこと。

訳注 3: Google Chrome の場合、類似のツールが利用できる。詳細については、Chrome DevTools | Tools for Web Developers | Google Developers を参照のこと。

訳注 4: Edge の場合も、類似のツールが利用できる。詳細については、Microsoft Edge Developer Tools - Microsoft Edge Development | Microsoft Docs を参照のこと。

検証

手順

ポップアップウインドウでないダイアログのトリガーとなるものページ内の全ての場所を探す。
Tab キーでその場所に移動して Enter キーを押下することで、ダイアログを開くことができることを確認する。
一度開いたら、タブ順序でダイアログが次の位置にあることを確認する。
ダイアログがボタン又はリンクのクリックイベントからトリガーされていることを確認する。
スクリプトによって生成された DOM を検証できるツールを用いて、DOM 内でダイアログが次にあることを確認する。

期待される結果

2.、3.、4. 及び 5. の結果が真である。

SCR38: プログレッシブエンハンスメントで設計されたウェブページに対して、適合している代替版を作成する

適用 (対象)

HTML with scripting.

これは、次の達成基準に関連する達成方法である:

適合要件 1 (適合レベル)

解説

この達成方法の目的は、プログレッシブエンハンスメントで設計されたウェブページに適合する代替バージョンを提供することである。この達成方法は、スクリプトを用いて達成する方法を次のように示している:

ウェブページの初期拡張バージョンを格納することで、後に拡張されたコンテンツのバージョンに対して「適合した代替バージョン」として機能できるようにし、かつ
すべての拡張されたバージョンのウェブページに対して、利用者がコンテンツを格納された初期拡張の代替バージョンに戻すことができる機能を実装する。

プログレッシブエンハンスメントで設計されたウェブページはサポートされたウェブ技術を HTML 基盤のレイヤーに適用できるようにするため、ウェブ対応機器 (サイズ、機能及びソフトウェア) の特徴を検出する。より高度なアクセス機器のさまざまな機能に合わせて拡張バージョンのページが作成される一方で、そのようなウェブページの基本的なコンテンツと機能は、よりシンプルなウェブ対応機器を使用している人なら誰でも HTML 基盤を通じて利用することができる。

現在の代替バージョンのウェブページの要件は次のようになっている: 「注記 4: 様々な技術環境又は利用者層に対応するために、複数の代替バージョンを提供してもよい。この場合、各バージョンは可能なかぎり適合したものでなければならず、適合要件 1 を満たすためには、そのうちの一つのバージョンが完全に適合したものでなければならない。」プログレッシブエンハンスメントで設計されたウェブページは、どのバージョンを完全に適合したものとして選ぶかという問題を残しているが、どんな利用者においても不利な状況におかれないようにする。

この課題の解決策の一つは、広範囲のウェブ対応機器がコンテンツにアクセス可能なため、拡張前のウェブページ (例: スクリプト、スタイル、HTML ではないプラグインが無効時に作成される HTML のソースコードの DOM の状態) を「完全に適合したバージョン」として選択することである。

注記: この達成方法はすべてのスクリプト、スタイル、プラグインを除外するが、これは WCAG 2.0 に適合するために必須ではないことを示す必要がある。制作者は類似した技術を使用することができるが、還元されたスタイルとスクリプトを「拡張前」のバージョンで保つことができる。

この技術は一つのバージョンで適合表明を行う方法を提供するが、制作者は各拡張版のウェブページが可能な限り適合するために作業し続けるべきである。

事例

事例 1: JavaScript を使用する

この事例は「accToggle.js」ファイル内で JavaScript を使用し、HTML ソースコードのみで作成された拡張前のウェブページを格納することで、後に拡張されたウェブページの「適合した代替バージョン」として機能させることができる。そして、利用者がウェブページを最初の拡張前の「適合した代替バージョン」に戻せるよう、すべての拡張されたウェブページに切り替えリンクを設置する。注記: 「sayhello.js」ファイルは単なる外部のペイロードファイルの例であり、必要な他の外部スクリプトに置き換えられる。

accToggle.js ファイル内のスクリプトは拡張前のバージョンを格納し、このバージョンの URL に #accessible という接尾辞を付与する。「WCAG 2.0 適合する代替版」という (すべての拡張されたバージョンのページにおいて、body 要素の最初の子要素として設置される) リンクをクリックすることにより、接尾辞に「#accessible」とついた URL に変化し、body 要素と head 要素内の HTML を拡張前のコードに初期化する。拡張前の状態はリンクから、又は URL をブラウザに直接入力することでアクセスできる。さらに、拡張前の「適合する代替版」にリンクが追加され、利用者がウェブページを拡張版にすることができる (これはブラウザの戻るボタンからでも可能)。

acctoggle.js ソースコード:


window.onload = function(event) {

    // 拡張前のコンテンツを保管する
    var initialHead = document.head.innerHTML;
    var initialBody = document.body.innerHTML;
    var initialURL = location.href;
    
    var runOnce = function() {
         // ページ読み込み毎に実行したいペイロード　例: Google Analytics コード
    }
    
    var setup = function() {
         // 適合している代替版のリンクを作成する

        var toggleEnhanced = document.querySelector("#toggle_enhanced");
        if (toggleEnhanced) {
            toggleEnhanced.outerHTML = "";
        }
        
        var nel = document.createElement("a");
        nel.id = "acctoggle";
        nel.setAttribute("href", "#accessible");
        nel.innerHTML = "WCAG 2.0 conforming alternate version";
        document.body.insertBefore(nel, document.body.firstChild);
        
         // ペイロード
        var s = document.createElement("SCRIPT");
        s.setAttribute("src", "sayhello.js");
        document.querySelector("HEAD").appendChild(s);   
       }
    
    setup();
    runOnce();
    
    window.onpopstate = function(event) {
        if (location.href.indexOf("#accessible") != -1) {
             // コンテンツを拡張前のバージョンに戻す
            document.head.innerHTML = initialHead;
            document.body.innerHTML = initialBody;
            
            // create enhanced version link
            var el = document.createElement("a");
            el.id = "toggle_enhanced";
            el.setAttribute("href", "");
            el.innerHTML = "Enhanced version";
            var back = function(e) {
                 e.preventDefault();
                 window.history.back();
            }
            el.addEventListener("click", back, false);
            document.body.insertBefore(el, document.body.firstChild);
        }
        if (location.href == initialURL) {
            setup();
        }
    };
}

HTML ウェブページソースコード:

<!DOCTYPE html>
  <html lang="en">
    <head>
        <title>Evaluera Ltd</title>
        <meta charset="UTF-8" />
        <script src="accSwitch.js"></script>
    </head>
    <body> 
        <h1>Test Page</h1>
        <p>Say: <span id="change">Goodbye</span></p>
    </body>
</html>

sayhello.js ソースコード


var change = document.querySelector("#change");
change.innerText = "Hello";

事例 2: EnhanceJS を使用する―プログレッシブエンハンスメントのアプリケーションを改善するために設計された Javascript フレームワーク

EnhanceJS は「高度なスタイルとスクリプトをページに適用する前に、JavaScript の主要な機能と CSS のサポートを最初にテストすることで、プログレッシブエンハンスメントのアプリケーションを改善するように設計された」オープンソースの JavaScript フレームワークである。さらに、デフォルトの EnhanceJS スクリプトは、利用者が拡張前のウェブページの状態に戻すことがでるよう、すべての拡張版のページに自動的に切り替えリンクを作成する。(EnhanceJS でデフォルトで設定されるこれを「低帯域幅版」と呼ぶ)。EnhanceJS ではこの設定は拡張前の状態が「低帯域幅版」ではなく、「WCAG 2.0 の適合している代替版」として認識されるよう変更されている。

HTML コンポーネント:

<!DOCTYPE html>
<html lang="en">
    <head>
    <script type="text/javascript" src="enhance.js"></script>
    <script type="text/javascript">
        // Run capabilities test
        enhance({
            loadStyles: [
                "example.css"
            ], 
            loadScripts: [
                "example.js"
            ],
            // text shown in enhanced mode
            forceFailText: "WCAG 2.0 conforming alternate version",
            // text shown in accessible mode
            forcePassText: "Enhanced version"
        });
    </script>
    </head>
    ....

参考リソース

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

検証

手順

拡張されたウェブページが「適合している代替版」へのリンクを含んでいる。
代替版が、オリジナルページの適合している代替版であり、かつ要求された適合レベルで WCAG 2.0 に適合していることを確認する。

期待される結果

1. 及び 2. の結果が真である。

5. サーバーサイドスクリプトの達成方法

SVR1: クライアントサイドではなく、サーバーサイドで自動リダイレクトを実装する

適用 (対象)

サーバーサイドスクリプト言語、及びリダイレクトための URL 又は URL パターンのあるサーバー環境設定ファイルを含む、サーバーサイドのウェブコンテンツ技術

これは、次の達成基準に関連する達成方法である:

達成基準 3.2.5 (要求による変化)
- クイックリファレンス 3.2.5 (要求による変化)
- 達成基準 3.2.5 (要求による変化)を理解する

解説

この達成方法の目的は、あるページ (利用者によって要求されたページ) が別のページにリダイレクトされたために、二つの新しいページが間断なく読みこまれることによって引き起こされる混乱を回避することである。いくつかのユーザエージェントは、利用者を指定された秒数の後に別のページにリダイレクトする HTML の meta 要素の使用をサポートしている。これは、一部の利用者、特にスクリーンリーダーを使用している利用者にとって、ページをアクセシブルではないものにしている。サーバーサイドのウェブコンテンツ技術は、利用者を混乱させないリダイレクトを実装する方法を提供している。サーバーサイドスクリプト又はサーバー環境設定ファイルで、3xx 番台のステータスコード、及び転送先の URL の Location ヘッダーを持つ適切な HTTP レスポンスをサーバーが送るようにできる。ブラウザがこのレスポンスを受けると、ロケーションバーが変わり、ブラウザは新しい URL のリクエストをする。

事例

事例 1: JSP/サーブレット

Java サーブレット又は JavaServer Pages (JSP) では、開発者は HttpServletResponse.sendRedirect(String url) を使用できる。

コード例:

…
public void doGet(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
…
  response.sendRedirect("/newUserLogin.do");
}

このコードは、302 ステータスコード (「Found」) 及び新しい URL の Location ヘッダーを含むレスポンスをユーザエージェントに送る。また、response.sendError(int code, String message) で、ステータスコードとしてインタフェース javax.servlet.http.HttpServletResponse で定義されている定数の一つを用いて、別のステータスコードに設定することも可能である。

コード例:

…
public void doGet(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
…
  response.sendError(response.SC_MOVED_PERMANENTLY, "/newUserLogin.do");
}

アプリケーションがセッションに依存するために、アプリケーションが URL のリライトに HttpServletResponse.encodeURL(String url) を使用するなら、メソッド HttpServletResponse.encodeRedirectURL(String url) が HttpServletResponse.sendRedirect(String url) の代わりに使用されるべきである。また、HttpServletResponse.encodeURL(String url) で URL をリライトして、それから HttpServletResponse.sendRedirect(String url) にこの URL を渡すことも可能である。

事例 2: ASP

VBScript で書かれた Active Server Page (ASP) では、開発者は Response.Redirect を使用できる。

コード例:


Response.Redirect "newUserLogin.asp"

又は

コード例:

Response.Redirect("newUserLogin.asp")

以下のコードは、特定の HTTP ステータスコードを含む、より完全な例である。

コード例:

Response.Clear
Response.Status = 301
Response.AddHeader "Location", "newUserLogin.asp"
Response.Flush
Response.End

事例 3: PHP

PHP では、開発者は header メソッドで生の HTTP ヘッダーを送ることができる。以下のコードは、301 ステータスコードと新しい場所を送る。ステータスが明示的に設定されないなら、リダイレクトのレスポンスは HTTP ステータスコード 302 を送る。

コード例:


<?php
header("HTTP/1.1 301 Moved Permanently");
header("Location: http://www.example.com/newUserLogin.php");
?>

事例 4: Apache

以下の例のようにして、開発者は Apache ウェブサーバーがリダイレクトを処理するように構成できる。

コード例:

redirect 301 /oldUserLogin.jsp http://www.example.com/newUserLogin.do

参考リソース

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

Use standard redirects: do not break the back button! (W3C QA Tip).
HTTP/1.1 Status Code Definitions: Redirection 3xx.
HTTP 301 Permanent Redirection Techniques by Shailesh N. Humbad.
Interface javax.servlet.http.HttpServletResponse in the Java Servlets 2.3 API documentation.
header in the PHP Manual.
Apache Module mod_alias in the Apache HTTP Server Version 2.2 Documentation describes how redirects can be specified in Apache 2.2.
Module mod_alias in the Apache HTTP Server Version 1.3 Documentation describes how redirects can be specified in Apache 1.3.

(今のところ、なし。)

検証

手順

別のウェブページ又はウェブページへのリンク又はプログラムによる参照を見つける。
評価されているウェブページ一式における URI への各リンク又はプログラムによる参照において、参照されたウェブページがクライアントサイドリダイレクトを引き起こすコード (例えば、meta 要素又はスクリプト) を含むかどうかを確認する。
評価されているウェブページ一式における URI への各リンク又はプログラムによる参照において、参照された URI がリダイレクトを引き起こさない、又は、タイムアウトなしのサーバーサイドリダイレクトをするかどうかを確認する。

期待される結果

2. の結果が偽であり、かつ 3. の結果が真である。

SVR2: 適合しているコンテンツからのみ、適合していないコンテンツにアクセスできるように、.htaccess を使用する

適用 (対象)

.htaccess をサポートしているウェブサーバー (一般的には Apache) 内にあるコンテンツで、コンテンツの適合版が不適合版の代替として提供されているもの

これは、次の達成基準に関連する達成方法である:

適合要件 1 (適合レベル)

解説

この達成方法の目的は、コンテンツの不適合なバージョンも利用可能な場合に、利用者が常にアクセシブルなバージョンにアクセスできることを保証することである。WCAG に適合していないフォーマットでコンテンツが提供される際でも、アクセシブルではないコンテンツの代替版が提供されていれば、そのサイト全体が適合していることになる。適合要件 4 は代替版が不適合なコンテンツ又はその URI からたどることができることを要求している。

不適合のコンテンツの中からアクセシブルなリンクを提供することは常に可能ではないため、この達成方法では制作者が不適合のコンテンツにその代替版として提供される URI、又は不適合のバージョンと代替版双方へのリンクを含むページからしかアクセスできないようにするために Apache のモジュール「mod_access」を使う方法について説明する。

事例

事例 1

次の .htaccess ファイルは、「accessible.html」からのリクエストではない限り、「inaccessible.html」から「accessible.html」へのリダイレクトを要求する Apache の mod_redirect モジュールを使用している。

コード例:


# アクセシブルではないコンテンツへのリクエストがaccessible.html
# という名前のファイルから来た場合、アクセシブルではないバージョン
# の表示を許可する環境変数をセットする。
SetEnvIf Referer .*(accessible.html)$ let_me_in
<FilesMatch ^(inaccessible.html)$>
    Order Deny,Allow
    Deny from all
    Allow from env=let_me_in
</FilesMatch>

# リクエストがaccessible.html以外から来た場合、
# エラーとしてアクセシブルなバージョンがある場所へと
# リダイレクトする。
ErrorDocument 403 /example_directory/accessible.html

事例 2

この例では、ドキュメントが複数のフォーマットで利用可能なディレクトリ構造を前提とする。そのフォーマットのうちのひとつは WCAG に宣言しているレベルで適合しておらず、「jna (全くアクセシブルではない: Just Not Accessible)」というファイル拡張子を使用している。これらのファイルは、.htaccess ファイルとともに全て「jna」というフォルダに保存されている。この .htaccess ファイルは、アクセシブルではないバージョンが存在しないページから、.jna の拡張子を持つファイルへの直接リクエストを、全ての利用可能なフォーマットが記載されているインデックスページへとリダイレクトするのを保証している。

コード例:


# アクセシブルではないコンテンツへのリクエストが
# http://example.com/documents/index.htmlにあるファイルから来た場合、
# アクセシブルではないバージョンの表示を許可する環境変数をセットする。
SetEnvIf Referer ^http://example.com/documents/index.html$ let_me_in
<FilesMatch ^(.*\.jna)$>
    Order Deny,Allow
    Deny from all
    Allow from env=let_me_in
</FilesMatch>

# リクエストがhttp://example.com/documents/index.html以外から来た場合、
# エラーとしてアクセシブルなバージョンがある場所へと
# リダイレクトする。
ErrorDocument 403 http://example.com/documents/index.html

参考リソース

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

検証

手順

.htaccess ファイルの使用に基づいてアクセシブルな代替が提供されるところで、宣言している適合レベルで WCAG に適合していないページを特定する。
不適合のコンテンツの URI を開く。
結果となるページが次のうちのいずれかであることを確認する:
1. 不適合のコンテンツの適合している代替版
2. 適合している代替版と不適合のコンテンツの両方へのリンクを含むページ

期待される結果

3.a. 又は 3.b. の結果が真である。

SVR3: 適合しているコンテンツからのみ、適合していないコンテンツにアクセスできるように、HTTP リファラを使用する

適用 (対象)

サーバーサイドのスクリプトを用いて生成されたコンテンツで、コンテンツの適合したバージョンが HTTP リファラによって不適合バージョンの代替として提供されているもの

これは、次の達成基準に関連する達成方法である:

適合要件 1 (適合レベル)

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

SVR3 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、不適合及び適合したバージョンが両方提供されているときに、利用者がコンテンツのアクセシブルなバージョンを取得できることを保証することである。

適合要件 1 は、「適合している代替版」がある限り、不適合なページが適合の範囲内に含まれることを認めている。コンテンツ制作者にとって、不適合なコンテンツの中から適合しているコンテンツへのアクセシビリティサポーテッドなリンクを含むことは常に可能とはいえない。そこで、不適合のバージョンへは適合しているページからしか到達できないようにするために、コンテンツ制作者はサーバーサイドのスクリプト技術 (例：PHP、ASP、JSP) に依存しなければならなくなる。

この達成方法は、不適合のコンテンツへは、適合しているページからしか到達できないことを保証するための、HTTP referer により提供される情報の利用方法について説明する。HTTP referer ヘッダーはユーザエージェントによって設定され、(もしあれば) ユーザエージェントが不適合なページを参照する際のページの URI を含む。

この方法を実装するために、コンテンツ制作者は不適合なページそれぞれについて、コンテンツの適合しているバージョンの URI を特定する。ページの不適合なバージョンへのリクエストを受け取った際に、サーバーは HTTP referer ヘッダーの値と、適合しているバージョンの URI を比較して、不適合バージョンへのリンクが適合しているバージョンからのものであるかどうかを判断する。不適合バージョンは HTTP referer が不適合バージョンの URI と一致したときにだけ提供される。それ以外の時には、利用者はコンテンツの適合したバージョンへとリダイレクトされる。HTTP リファラヘッダー内の URI を比較する際に、URI 中にクエリーや target のような関連のない変化も考慮に入れる必要があることに注意すべきである。

事例

事例 1: インタラクティブな物理プロセスのデモ

オンラインの物理の授業では、インタラクティブな物理プロセスのデモを提供するために専用のモデリング言語を使用する。そのモデリング言語のためのユーザエージェントは支援技術との互換性がない。そのサイトは利用者が適合するプロセスとモデルの説明を含むページからインタラクティブなデモにアクセスしようとしない限り、サーバーがそのリクエストを不適合バージョンへのリンクを含む、適合しているページへとリダイレクトする、HTTP リファラを使用するスクリプトを含んでいる。生徒は不適合のインタラクティブなバージョンへのアクセスを選択する事ができるが、そうしない生徒もプロセスについて学ぶことができる。

事例 2: PHP で Http リファラを使う

次の例は、この達成方法が PHP でどのように使われるかを説明している。conforming.php と non-conforming.php という不適合なコンテンツへのアクセスが適合しているコンテンツからのみとなるようにするために連携する二つのファイルを含む。

conforming.php:

コード例:


<!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">
	<head>
    		<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
    		<title>Conforming Content</title>
    	</head>
	<body>
		<h1>This is a conforming page</h1>
		<p>From here, you can visit the <a href="non-conforming.php">non-conforming 
		page</a>. </p>
	</body>
</html>

non-conforming.php:

コード例:


<?php 
// リクエストが「conforming.php」という文字列を含むファイルから来た場合、ページをレンダリングする。
	if(stristr($_SERVER['HTTP_REFERER'], "conforming.php")) {
?>

<!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">
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
		<title>Non-Conforming Content</title>
	</head>
	<body>
		<h1>This is a non-conforming page</h1>
		<p>Because you came from <?php echo $_SERVER['HTTP_REFERER']; ?>, you are 
			able to view the content on this page. </p>
	</body>
</html>
<?php
}
// 参照するページがconforming.phpではない場合、利用者を適合しているバージョンにリダイレクトする。
else  {
header("Location: conforming.php");
}
?>

実装例として Conforming content が利用できる。

検証

手順

不適合コンテンツに対して、WCAG に適合している代替版が提供されている場合:

HTTP リファラに基づいてアクセシブルな代替版が提供されている場合、宣言している適合レベルで WCAG に適合していないページを特定する。
不適合のコンテンツの URI を開く。
開いたページが次のうちの一つである:
1. 不適合のコンテンツの適合している代替版
2. 適合している代替版と不適合のコンテンツの両方へのリンクを含むページ

期待される結果

3.a. 又は 3.b. の結果が真である。

SVR4: 適合している代替版の表示に関する設定を利用者が行えるようにする

適用 (対象)

設定を保存するためにサーバーサイドのスクリプトを用いて生成されたコンテンツ

これは、次の達成基準に関連する達成方法である:

適合要件 1 (適合レベル)

解説

この達成方法の目的は、ウェブページの適合している代替版の設定を利用者が選択できるメカニズムを提供することである。

利用者が適合している代替版を見ることができるような設定を提供するにはいくつかの方法が可能である。一般的な方法としては、ウェブサーバーがページを修正する、又は利用者を代替版にリダイレクトするのに使うセッション又は永続的なクッキーを設定するサーバーサイドのプロセスのトリガーとなるリンクを提供する方法がある。他の方法には、利用者がウェブページ又はサービスにアクセスする際にサインインするシステムへのログイン情報の一部として利用者ごとの選択肢を提供する方法がある。

不適合なページで提供されるメカニズムは、代替版を必要とする利用者が、それを探して利用するためにアクセシブルである必要がある。そのメカニズム自体は宣言しているアクセシビリティレベルに適合しているべきである。

事例

事例 1: 利用者設定を保存するためにセッション又は永続的なクッキーを設定する

あるウェブサイトは、サイト内のページには「設定」ページへのリンクを提供している。このページには、サイトの代替版を見るためのオプションがある。好みによってページのさまざまな見方があるかもしれないし、利用者はサイトの完全な代替版を見たいかもしれない。その設定はサイト上で動画が含まれる部分ではキャプションを表示するものかもしれない。また、主となるサイトが、代替版からしかわからないアクセシビリティ適合についての問題を含んでいるために提供されているのかもしれない。

あるウェブページの制作者はクッキーを使って設定を扱うことがある。それは、PHP のようなサーバーサイドのスクリプトを用いて扱われるかもしれない。

設定のページは例えば次のように提供される:

コード例:

 <!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">
      <head>
      <title>Site Preferences</title>
  </head>
  <body>
      <h1>Site Preferences</h1>
      <form id="form1" name="site_prefs" method="post" action="pref.php">
          <fieldset>
              <legend>Which version of the site do you want to view?</legend>
              <input type="radio" name="site_pref" id="site_pref_reg" value="reg" />
              <label for="site_pref_reg">Main version of site</label>
              <input type="radio" name="site_pref" id="site_pref_axx" value="axx" />
              <label for="site_pref_axx">Accessibility-conforming version</label>
          </fieldset> 
      </form>
  </body>
  </html>

フォームは処理のためにpref.phpのファイルへと送信される。クッキーが設定され、この単純な例では、利用者のブラウザはサイトのトップページへと移動する。

pref.php:

コード例:


<?php
    if(isset($site_pref)) {
        setcookie("site_pref",$site_pref, time() + (86400 * 30)); //30日に設定
        header("location: http://www.example.com"); //トップページへとリダイレクト
    }
?>

トップページは利用者の設定を実装するコードから始まる。

index.php:

コード例:

<?
if(isset($site_pref)) {
	if($site_pref="axx") {
	header("location: ./accessible/index.php");
}
?>
<!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">
<head>
...

ログインを必要とするシステムでは、設定は利用者のデータベース記録に保存され、利用者が見るページを生成するサーバーサイドのスクリプトによって参照される。

参考リソース

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

PHP: setcookie - Manual

検証

手順

そのサイトのページの表示方法についての設定を変更する。
各不適合なページから、設定そのもの、又は設定できるページへのリンクにアクセスできることを確認する。
ウェブページが選択した設定に応じて表示されることを確認する。
設定が行われた時に、ウェブページが宣言通りに適合していることを確認する。
結果となるページが元のページの適合している代替版となっていることを確認する。

期待される結果

2. 及び 3. の結果が真である。

SVR5: HTTP ヘッダーにデフォルト言語を指定する

適用 (対象)

サーバーサイド技術 (HTTP ヘッダーを設定するサーバーサイドのスクリプト言語及びサーバー設定ファイルを含む)

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.1 (ページの言語)
- クイックリファレンス 3.1.1 (ページの言語)
- 達成基準 3.1.1 (ページの言語)を理解する

解説

この達成方法の目的は、コンテンツの対象者を特定するために、ウェブページの主たる自然言語に関する情報を提供することである。HTTP Content-Language ヘッダーには、一つ以上の言語コードのリストを含めることが可能で、ユーザエージェントとサーバーとの間での言語ネゴシエーションに用いられる。ユーザエージェントで言語設定が正しく設定されていれば、言語ネゴシエーションによって利用者は自分が設定した自然言語に合うコンテンツを見つけることができる。

ただし、HTTP Content-Language ヘッダーは、コンテンツを処理するのに用いられる自然言語を特定するためのものではないことに注意しなければならない。コンテンツを処理する自然言語は、マークアップ言語の lang 属性や xml:lang 属性などによって特定することができる。

この達成方法は、lang 属性または xml:lang 属性の例で明記されているように、文書の主たる自然言語を HTTP Content-Language ヘッダーで挙げるようにするものである。

訳注: 言語ネゴシエーション (language negotiation) というのは、Accept-Language によるコンテントネゴシエーションのことを指していると思われるが、このときネゴシエーションに使われるのは "Content-Language" ではなく、クライアントが送る "Accept-Language" の値であると考えられる。

事例

事例 1: Java サーブレット及び JSP によるコンテンツの自然言語設定

Java サーブレット又は JavaServer Pages (JSP) では、開発者は response.setHeader("Content-Language", lang)を用いることが可能で、"lang" は言語タグを表す (例えば、英語なら "en"):

コード例:

…
public void doGet(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException 
{
…
  response.setHeader("Content-Language", "en");
  PrintWriter out = response.getWriter();
…
}

事例 2: PHP によるコンテンツの自然言語設定

PHP では、開発者は header メソッドで生の HTTP ヘッダーを送ることができる。次の例では、自然言語をフランス語に設定している:

コード例:

<?php  header('Content-language: fr');  …  ?>

参考リソース

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

W3C Internationalization FAQ: HTTP and meta for language information

Declaring metadata about the language(s) of the intended audience in Authoring HTML: Language declarations - W3C Working Group Note 3 June 2014.

RFC 7321 3.1.3.2. Content-Language

header in the PHP Manual.

H57: html 要素の言語属性を使用する

検証

手順

Live HTTP Header ビューアを用いて、"Content-Language" ヘッダーの値を調べる。
訳注: 「Live HTTP Header」が正確に何を指すのか不明であるが、代わりに各種ブラウザの開発ツールで確かめることができる。リソース読み込み時間の測定 | Tools for Web Developers | Google Developers、ネットワークモニター - 開発ツール | MDN、Microsoft Edge DevTools - Network - Microsoft Edge Development | Microsoft Docs がそれぞれ参考になる。
その値がウェブページの主たる自然言語と一致していることを確認する。

期待される結果

2. の結果が真である。

6. SMILの達成方法

SM1: SMIL 1.0 で拡張音声解説を追加する

適用 (対象)

SMIL 1.0 プレーヤーが利用可能な場合

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、会話の合間に入れられるよりも多くの音声解説を、視聴覚素材に付加することである。

SMIL 1.0 にはこれを達成する簡単な方法がないが、連続して順番に再生される複数のファイルに、音声ファイル及び映像ファイルを分割することによって実装できる。この方法によって追加した音声解説は、視聴覚コンテンツが停止している間に再生される。映像ファイルの最後のフレームは、画面に表示されたまま一時停止し、その間に音声ファイルが再生される。

これにより、映像は最初から最後まで再生されるように見えながらも、ところどころで停止して、その間に長めの音声解説が提供される。そして、音声解説が終了すると、映像の再生が自動的に再開する。

この拡張音声解説のオン／オフを操作するには、スクリプトを使用して、拡張音声解説を含んだ SMIL スクリプト及び含まない SMIL スクリプトの二つの間で切り替えることによって実装できる。又は、スクリプトを使用して、拡張音声解説を SMIL ファイルに追加したり SMIL ファイルから削除したりすることもできる。そうすることで、映像クリップは、単純に順序どおり再生されることになる。

スクリプトが使用できない場合は、二つのバージョンの映像を提供することによって可能となる。つまり、一つは拡張音声解説を含んだバージョン、もう一つは含まないバージョンを提供するのである。

事例

事例 1: 拡張音声解説のある SMIL 1.0 の映像、メインのメディアを 4 箇所で停止して拡張音声解説を挿入している

コード例:


<?xml version="1.0" encoding="UTF-8"?>
<smil xmlns:qt="http://www.apple.com/quicktime/resources/smilextensions" 
xmlns="http://www.w3.org/TR/REC-smil" qt:time-slider="true">
  <head>
    <layout>
      <root-layout background-color="black" height="266" width="320"/>
      <region id="videoregion" background-color="black" top="26" left="0" 
      height="144" width="320"/>
    </layout>
  </head>
  <body>
  <par>
   <seq>
     <par>
       <video src="video.rm" region="videoregion" clip-begin="0s" clip-end="5.4" 
       dur="8.7" fill="freeze" alt="videoalt"/>   
       <audio src="no1.wav" begin="5.4" alt="audio alt"/>
     </par>
     <par>
       <video src="video.rm" region="videoregion" clip-begin="5.4" clip-end="24.1" 
       dur="20.3" fill="freeze" alt="videoalt"/>
       <audio src="no2.wav" begin="18.7" alt="audio alt"/>
     </par>
     <par>
       <video src="video.rm" region="videoregion" clip-begin="24.1" clip-end="29.6" 
       dur="7.7" fill="freeze" alt="videoalt"/>
       <audio src="no3.wav" begin="5.5" alt="audio alt"/>
     </par>
     <par>
       <video src="video.rm" region="videoregion" clip-begin="29.6" clip-end="34.5" 
       dur="5.7" fill="freeze" alt="videoalt"/>
       <audio src="no4.wav" begin="4.9" alt="audio alt"/>
     </par>
     <par>
       <video src="video.rm" region="videoregion" clip-begin="77.4" alt="video alt"/>
     </par>
   </seq>
  </par>
</body>
</smil>

上記のマークアップは、五つの <par> セグメントに分割されている。各セグメントに <video> と <audio> のタグが一つずつある (ただし、最後の <par> に <audio> がないのは意図的なものである)。拡張音声解説の通常の使い方は、音声解説が提供される間、メインのメディアを一時停止するというものである。SMIL 1.0でこれを実現するには、映像クリップの開始と終了を指定する「clip-begin」と「clip-end」を設定して、その「clip-begin」と「clip-end」で定義されるよりも長い再生時間をクリップに設定する。fill=「freeze」は、拡張音声解説の再生中、映像の最後のフレームを保持する。<audio> タグには「begin」の属性があり、その前の <video> タグで定義された「clip-end」の値と同じ値を持っている。

「clip-begin」「clip-end」「dur」の値を決めるにあたっては、音声解説が開始及び終了する前の映像部分の時間と、拡張音声解説の全体の長さを調べる必要がある。「clip-begin」と「clip-end」は、それ自体の値を定義するが、「dur」の値は、「clip-begin」と「clip-end」によって定義される拡張音声解説及び映像クリップを合計した長さとなる。最初の <par> では、映像クリップが 0 秒で始まり、5.4 秒で終わる。そして記述の長さは 3.3 秒だ。このため、「dur」の値は、5.4 + 3.3 = 8.7 秒となる。

参考リソース

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

検証

手順

拡張音声解説のあるファイルを再生する。
音声解説のあるファイルを再生する。
映像がところどころ一時停止して、拡張音声解説が再生されることを確認する。

期待される結果

3. の結果が真である。

SM2: SMIL 2.0 で拡張音声解説を追加する

適用 (対象)

SMIL 2.0 プレーヤーが利用可能な場合

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、会話の合間に入れられるよりも多くの音声解説を、視聴覚素材に付加することである。

SMIL 2.0 では、特定の音声ファイルを特定のタイミングで再生するよう指定し、音声ファイルが再生される間は、画面が表示されたまま一時停止できる。

これにより、映像は最初から最後まで再生されるように見えながらも、ところどころで停止して、その間に長めの音声解説が提供される。そして、音声解説が終了すると、映像の再生は自動的に再開する。

事例

事例 1: 拡張音声解説のある映像

コード例:


<smil xmlns="//www.w3.org/2001/SMIL20/Language"> 
<head> 
<layout> 
<root-layout backgroundColor="black" height="266" width="320"/> 
<region id="video" backgroundColor="black" top="26" left="0" 
height="144" width="320"/> 
</layout> 
</head> 
<body>	 
<excl> 
<priorityClass peers="pause"> 
<video src="movie.rm" region="video" title="video" alt="video" /> 
<audio src="desc1.rm" begin="12.85s" alt="Description 1" /> 
<audio src="desc2.rm" begin="33.71s" alt="Description 2" /> 
<audio src="desc3.rm" begin="42.65s" alt="Description 3" /> 
<audio src="desc4.rm" begin="59.80s" alt="Description 4" /> 
</priorityClass> 
</excl> 
</body> 
     </smil>

参考リソース

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

検証

手順

拡張音声解説のあるファイルを再生する。
映像がところどころ一時停止して、拡張音声解説が再生されることを確認する。

期待される結果

2. の結果が真である。

SM6: SMIL 1.0 で音声解説を提供する

適用 (対象)

SMIL 1.0 プレーヤーが利用可能な場合

これは、次の達成基準に関連する達成方法である:

解説

この達成方法の目的は、全盲又は視聴覚素材の映像を見るのが困難な利用者が、その素材の情報を得られるようにすることである。この達成方法では、視聴覚素材の会話の合間に入る音声解説によって、映像の説明が提供される。

事例

事例 1: QuickTime プレーヤー向けの SMIL 1.0 の音声解説の例

コード例:

 
<?xml version="1.0" encoding="UTF-8"?>
<smil xmlns:qt="http://www.apple.com/quicktime/resources/smilextensions" 
  xmlns="http://www.w3.org/TR/REC-smil" qt:time-slider="true">
  <head>
    <layout>
      <root-layout background-color="black" height="266" width="320"/>
      <region id="videoregion" background-color="black" top="26" left="0" 
      height="144" width="320"/>
    </layout>
  </head>
  <body>
    <par>
      <video dur="0:01:20.00" region="videoregion" src="salesdemo.mov" 
      alt="Sales Demo"/>
      <audio dur="0:01:20.00" src="salesdemo_ad.mp3" 
      alt="Sales Demo Audio Description"/>
    </par>
  </body>
</smil>

事例 2: RealTime プレーヤー向けの SMIL 1.0 の音声解説の例

コード例:


<?xml version="1.0" encoding="UTF-8"?>
<smil xmlns="http://www.w3.org/TR/REC-smil">
  <head>
    <layout>
      <root-layout background-color="black" height="266" width="320"/>
      <region id="videoregion" background-color="black" top="26" left="0" 
      height="144" width="320"/>
    </layout>
  </head>
  <body>
    <par>
      <video src="salesdemo.mov" region="videoregion" title="Sales Demo" 
      alt="Sales Demo"/>
      <audio src="salesdemo_ad.mp3" title="audio description" 
      alt="Sales Demo Audio Description"/>
    </par>
  </body>
</smil>

参考リソース

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

検証

手順

(デフォルトで常に再生されている場合を除いて、) コンテンツ／プレーヤーから音声解説を再生する方法を見つける。
音声解説のあるファイルを再生する。
音声解説が再生されるかどうかを確認する。

期待される結果

3. の結果が真である。

SM7: SMIL 2.0 で音声解説を提供する

適用 (対象)

SMIL 2.0 プレーヤーが利用可能な場合

これは、次の達成基準に関連する達成方法である:

解説

事例

事例 1: RealMedia プレーヤー向けの SMIL 2.0 の音声解説の例

コード例:


<smil xmlns="//www.w3.org/2001/SMIL20/Language">
  <head>
    <layout>
      <root-layout backgroundColor="black" height="266" width="320"/>
      <region id="video" backgroundColor="black" top="26" left="0" 
      height="144" width="320"/>
    </layout>
  </head>
  <body>
    <par>
      <video src="salesdemo.mpg" region="video" title="Sales Demo" 
      alt="Sales Demo"/>
      <audio src="salesdemo_ad.mp3" begin="33.71s" title="audio description" 
      alt="Sales Demo Audio Description"/>
    </par>
  </body>
</smil>

この例は、<audio> 及び <video> タグを1個ずつ含んだ <par> セグメントを示している。音声の再生は、即座には開始されない。

参考リソース

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

検証

手順

(デフォルトで常に再生されている場合を除いて、) コンテンツ／プレーヤーから音声解説を再生する方法を見つける。
音声解説のあるファイルを再生する。
音声解説が再生されるかどうかを確認する。

期待される結果

3. の結果が真である。

SM11: SMIL 1.0 で同期したテキストストリームによるキャプションを提供する

適用 (対象)

SMIL 1.0

これは、次の達成基準に関連する達成方法である:

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

SM11 に関するユーザエージェントサポートノートを参照のこと。

解説

この達成方法の目的は、耳の聞こえない利用者や視聴覚素材の会話の聞き取りが困難な利用者が、その素材を見て理解できるようにすることである。この達成方法では、会話と重要な音をすべて、画面上のキャプション領域に表示されるテキストストリームで提供する。

SMIL 1.0 では、映像とキャプションに別々の領域を定義することができる。キャプションと映像の再生は同期されて、キャプションのテキストが画面上のある領域に表示される間、それに対応する映像が別の領域に表示される。

事例

事例 1: Quicktime プレーヤー向けの SMIL 1.0 のキャプションの例

コード例:

 
<?xml version="1.0" encoding="UTF-8"?>
<smil xmlns:qt="http://www.apple.com/quicktime/resources/smilextensions" 
  xmlns="http://www.w3.org/TR/REC-smil" qt:time-slider="true">
  <head>
    <layout>
      <root-layout width="320" height="300" background-color="black"/>
      <region top="0" width="320" height="240" left="0" background-color="black" 
      id="videoregion"/>
      <region top="240" width="320" height="60" left="0" background-color="black" 
      id="textregion"/>
    </layout>
  </head>
  <body>
    <par>
      <video dur="0:01:20.00" region="videoregion" src="salesdemo.mov" 
      alt="Sales Demo"/>
      <textstream dur="0:01:20.00" region="textregion" src="salesdemo_cc.txt" 
      alt="Sales Demo Captions"/>
    </par>
  </body>
</smil>

事例 2: RealMedia プレーヤー向けの SMIL 1.0 のキャプションの例

コード例:

 
<?xml version="1.0" encoding="UTF-8"?>
<smil xmlns="http://www.w3.org/TR/REC-smil">
  <head>
    <layout>
      <root-layout background-color="black" height="310" width="330"/>
      <region id="video" background-color="black" top="5" left="5" 
      height="240" width="320"/>
      <region id="captions" background-color="black" top="250" 
      height="60" left="5" width="320"/>
    </layout>
  </head>
  <body>
    <par>
      <video src="salesdemo.mpg" region="video" title="Sales Demo" 
      alt="Sales Demo"/>
      <textstream src="salesdemo_cc.rt" region="captions" 
      system-captions="on" title="captions" 
      alt="Sales Demo Captions"/>
    </par>
  </body>
</smil>

この例は、 <video> 及び <textstream> タグを 1 個ずつ含んだ <par> セグメントを示している。system-captions 属性は、利用者の使っているプレーヤーのキャプション設定がキャプションの表示を選択している場合のみ、テキストストリームを表示すべきであることを示している。 <layout> のセクションは、映像及びキャプションに使用する領域を定義している。

事例 3: 内部テキストストリームを伴った SMIL 1.0 のキャプションの例

コード例:

 
<?xml version="1.0" encoding="UTF-8"?>
<smil xmlns="http://www.w3.org/TR/REC-smil">
  <head>
    <layout>
      <root-layout background-color="black" height="310" width="330"/>
      <region id="video" background-color="black" top="5" left="5" 
      height="240" width="320"/>
      <region id="captions" background-color="black" top="250" 
      height="60" left="5" width="320"/>
    </layout>
  </head>
  <body>
    <par>
      <video src="salesdemo.mpg" region="video" title="Sales Demo" 
      alt="Sales Demo"/>
      <text src="data:,This%20is%20inline%20text." region="captions" begin="0s" 
      dur="3" alt="Sales Demo Captions">
        <param name="charset" value="iso-8859-1"/>
        <param name="fontFace" value="System"/>
        <param name="fontColor" value="yellow"/>
        <param name="backgroundColor" value="blue"/>
      </text>
    </par>
  </body>
</smil>

この例は、同期したテキストストリームをSMILファイル内に有する <text> 要素を示している。

参考リソース

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

SM12: SMIL 2.0 で同期したテキストストリームによるキャプションを提供する

検証

手順

プレーヤーにキャプションの設定がある場合には、キャプションの表示を有効にする。
キャプションのあるファイルを再生する。
キャプションが表示されるかどうかを確認する。

期待される結果

3. の結果が真である。

SM12: SMIL 2.0 で同期したテキストストリームによるキャプションを提供する

適用 (対象)

SMIL 2.0

これは、次の達成基準に関連する達成方法である:

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

SM12 に関するユーザエージェントサポートノートを参照のこと。

解説

SMIL 2.0 では、映像とキャプションに別々の領域を定義することができる。キャプションと映像の再生は同期されて、キャプションのテキストが画面上のある領域に表示され、それに対応する映像が別の領域に表示される。

事例

事例 1: RealMedia プレーヤー向けの SMIL 2.0 のキャプションの例

コード例:


<?xml version="1.0" encoding="UTF-8"?>
<smil xmlns="//www.w3.org/2001/SMIL20/Language">
  <head>
    <layout>
      <root-layout backgroundColor="black" height="310" width="330"/>
      <region id="video" backgroundColor="black" top="5" left="5" 
      height="240" width="320"/>
      <region id="captions" backgroundColor="black" top="250" 
      height="60" left="5" width="320"/>
    </layout>
  </head>
  <body>
    <par>
      <video src="salesdemo.mpg" region="video" title="Sales Demo"
      alt="Sales Demo"/>
      <textstream src="salesdemo_cc.rt" region="captions" systemCaptions="on" 
      title="captions" alt="Sales Demo Captions"/>
    </par>
  </body>
</smil>

この例は、<video> および <textstream> タグを1個ずつ含んだ <par> セグメントを示している。systemCaptions 属性は、利用者の使っているプレーヤーのキャプション設定がキャプションの表示を選択している場合のみ、テキストストリームを表示すべきであることを示している。<layout> のセクションは、映像及びキャプションに使用する領域を定義している。

事例 2: RealMedia プレーヤー向けの内部テキストストリームを伴った SMIL 2.0 のキャプションの例

コード例:


<?xml version="1.0" encoding="UTF-8"?>
<smil xmlns="//www.w3.org/2001/SMIL20/Language">
  <head>
    <layout>
      <root-layout backgroundColor="black" height="310" width="330"/>
      <region id="video" backgroundColor="black" top="5" left="5" 
      height="240" width="320"/>
      <region id="captions" backgroundColor="black" top="250" 
      height="60" left="5" width="320"/>
    </layout>
  </head>
  <body>
    <par>
      <video src="salesdemo.mpg" region="video" title="Sales Demo" 
      alt="Sales Demo"/>
      <text src="data:,This%20is%20inline%20text." region="captions" 
      begin="0s" dur="3">
        <param name="charset" value="iso-8859-1"/>
        <param name="fontFace" value="System"/>
        <param name="fontColor" value="yellow"/>
        <param name="backgroundColor" value="blue"/>
      </text>
      <text src="data:,This%20is%20a%20second%20text." 
      region="captions" begin="3s" dur="3">
        <param name="charset" value="iso-8859-1"/>
        <param name="fontFace" value="System"/>
        <param name="fontColor" value="yellow"/>
        <param name="backgroundColor" value="blue"/>
      </text>
    </par>
  </body>
</smil>

この例は、同期したテキストストリームを SMIL ファイル内に有する <text> 要素を示している。

参考リソース

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

SM11: SMIL 1.0 で同期したテキストストリームによるキャプションを提供する

検証

手順

プレーヤーにキャプションの設定がある場合には、キャプションの表示を有効にする。
キャプションのあるファイルを再生する。
キャプションが表示されることを確認する。

期待される結果

3.の結果が真である。

SM13: SMIL 1.0 で、同期した映像ストリームを通じて手話通訳を提供する

適用 (対象)

SMIL 1.0 プレーヤーが利用可能な場合

これは、次の達成基準に関連する達成方法である:

達成基準 1.2.6 (手話 (収録済) )
- クイックリファレンス 1.2.6 (手話 (収録済) )
- 達成基準 1.2.6 (手話 (収録済) )を理解する

解説

この達成方法の目的は、耳が聞こえないか、またはそうでなくとも、視聴覚コンテンツにおいて発話を聞くことに問題のある利用者に、コンテンツを閲覧できる方法を提供することである。この達成方法では、発話と重要な音の全てがキャプション領域に表示される手話通訳の映像によって入手できる。

SMIL 1.0 では、二つの映像のために別々の領域を定義できる。二つの映像再生が同期していて、画面の一つの領域に本編のビデオを表示し、もう一つの領域に本編に対する手話通訳の映像を表示する。

事例

事例 1: QuickTime プレーヤーでの SMIL 1.0 による手話通訳のサンプル

コード例:

 
<?xml version="1.0" encoding="UTF-8"?>
<smil xmlns:qt="http://www.apple.com/quicktime/resources/smilextensions" 
  xmlns="http://www.w3.org/TR/REC-smil" qt:time-slider="true">
  <head>
    <layout>
      <root-layout width="320" height="300" background-color="black"/>
      <region top="0" width="320" height="240" left="0" background-color="black" 
      id="videoregion"/>
      <region top="240" width="320" height="60" left="0" background-color="black" 
      id="signingregion"/>
    </layout>
  </head>
  <body>
    <par>
      <video dur="0:01:20.00" region="videoregion" src="salesdemo.mov" 
      alt="Sales Demo"/>
      <video dur="0:01:20.00" region="signingregion" system-captions="on" 
      src="salesdemo_si.mov" alt="Sales Demo Sign Language Interpretation"/>
    </par>
  </body>
</smil>

事例 2: RealMedia プレーヤーでの SMIL 1.0 手話のサンプル:

コード例:

 
<?xml version="1.0" encoding="UTF-8"?>
<smil xmlns="http://www.w3.org/TR/REC-smil">
  <head>
    <layout>
      <root-layout background-color="black" height="310" width="330"/>
      <region top="0" width="320" height="240" left="0" background-color="black"
       id="videoregion"/>
      <region top="240" width="320" height="60" left="0" background-color="black" 
      id="signingregion"/>
    </layout>
  </head>
  <body>
    <par>
      <video dur="0:01:20.00" region="videoregion" src="salesdemo.mov" 
      alt="Sales Demo"/>
      <video dur="0:01:20.00" region="signingregion" system-captions="on" 
      src="salesdemo_si.mov" alt="Sales Demo Sign Language Interpretation"/>
    </par>
  </body>
</smil>

この事例では、二つの <video>タグを含む <par>セグメントを示している。system-captions 属性は、利用者のプレーヤーの字幕設定が、字幕を表示する選択になっているとき、手話の映像が表示されるべきであることを示す。<layout>セクションは、本編の映像と手話通訳の映像に割り当てる領域を定義している。

参考リソース

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

SM14: SMIL 2.0 で、同期した映像ストリームを通じて手話通訳を提供する

検証

手順

(手話通訳が常に表示される場合を除いて、) 手話通訳が表示されるように、コンテンツ内又はプレーヤーのコントロールを有効にする。
手話通訳を含むファイルを再生する。
手話通訳が表示されるかどうかを確認する。

期待される結果

3. の結果が真である。

SM14: SMIL 2.0 で、同期した映像ストリームを通じて手話通訳を提供する

適用 (対象)

SMIL 2.0

これは、次の達成基準に関連する達成方法である:

達成基準 1.2.6 (手話 (収録済) )
- クイックリファレンス 1.2.6 (手話 (収録済) )
- 達成基準 1.2.6 (手話 (収録済) )を理解する

解説

SMIL 2.0 では、二つの映像のために別々の領域を定義できる。二つの映像再生が同期していて、画面の一つの領域に本編のビデオを表示し、もう一つの領域に本編に対する手話通訳の映像を表示する。

事例

事例 1: RealMedia プレーヤーでの SMIL 2.0 手話ビデオのサンプル

コード例:


<smil xmlns="http://www.w3.org/2001/SMIL20/Language">
  <head>
    <layout>
      <root-layout backgroundColor="black" height="310" width="330"/>
      <region id="video" backgroundColor="black" top="5" left="5" 
      height="240" width="320"/>
      <region id="signing" backgroundColor="black" top="250" 
      height="60" left="5" width="320"/>
    </layout>
  </head>
  <body>
    <par>
      <video src="salesdemo.mpg" region="video" title="Sales Demo" 
      alt="Sales Demo"/>
      <video src="salesdemo_signing.mpg" 
      region="signing" systemCaptions="on" 
      title="sign language interpretation" 
      alt="Sales Demo Sign Language Interpretation"/>
    </par>
  </body>
</smil>

参考リソース

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

SM13: SMIL 1.0 で、同期した映像ストリームを通じて手話通訳を提供する

検証

手順

(手話通訳が常に表示される場合を除いて、) 手話通訳が表示されるように、コンテンツ内又はプレーヤーのコントロールを有効にする。
手話通訳を含むファイルを再生する。
手話通訳が表示されるかどうかを確認する。

期待される結果

3. の結果が真である。

7. プレーンテキストの達成方法

T1: 段落に、標準的なテキストの書式の表現法を使用する

適用 (対象)

プレーンテキストのドキュメント。マークアップを含むウェブコンテンツ技術は対象外

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

解説

この達成方法の目的は、プレーンテキストのドキュメントにおいて、段落であることが分かるようにすることである。段落は、まとまりのあるテキストのブロックで、例えば、関連する複数の文章によって一つのトピックを形成したり、より大きなトピックの中でまとまりのある一部分を形成したりするものである。

段落の始まりは、次のものによって示される。

コンテンツの始まり (つまり、その段落が文書内で最初のコンテンツとなっている)、又は
段落のテキストの前にある 1 行の空白行

段落の終わりは、次のものによって示される。

コンテンツの終わり (つまり、その段落が文書内で最後のコンテンツとなっている)、又は
段落のテキストの後にある 1 行もしくは複数の空白行

空白行には、何もないか、又はスペースやタブなどの印刷できない文字が含まれていて、そのすぐ後に新しい行がある。

事例

事例 1

二つの段落。それぞれが 1 行の空白行で始まり、1 行の空白行で終わっている。

コード例:


						
This is the first sentence in this
paragraph. Paragraphs may be long
or short.
   
    In this paragraph the first line is
indented. Indented and non-indented
sentences are allowed. White space within
the paragraph lines is ignored in
defining paragraphs. Only completely blank
lines are significant.

参考リソース

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

(今のところ、なし。)

検証

手順

それぞれの段落に対して:

段落の前に 1 行の空白行がある、又はその段落がウェブページの最初のコンテンツであることを確認する。
段落の後に少なくとも 1 行の空白行がある、又はその段落がウェブページの最後のコンテンツであることを確認する。
段落内に空白行がないことを確認する。

期待される結果

それぞれの段落について、上記の全ての結果が真である。

T2: リストに、標準的なテキストの書式の表現法を使用する

適用 (対象)

プレーンテキストのドキュメント。マークアップを含むウェブコンテンツ技術は対象外

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

解説

この達成方法の目的は、テキストの書式の規則を用いて、関連する項目のシンプルなリストを作ることである。ただし、階層構造になったリストや入れ子のリストは、この達成方法では表現できないため、別のウェブコンテンツ技術を使って表現すべきである。

リストは、連続したリスト項目によって構成される。そして、リスト項目は、ラベルで始まる段落である。順不同のリストでは、アスタリスク、ダッシュ、箇条書きの行頭文字などをラベルとして用いる。ただし、同じリスト内では全ての項目に同じラベル文字を使わなければならない。順序付きリストでは、英数字をラベルとして用い、ピリオドや閉じ括弧をつける。ラベルは、次のいずれかの昇順になっていなければならない。

数字の場合、数字の順に並んでいなければならない。
アルファベットの場合、アルファベット順又はローマ数字として解釈される際は数字の順に並んでいなければならない。

事例

事例 1: 順不同リスト

コード例:


						
- unordered list item
 
- unordered list item
 
- unordered list item

事例 2: 数字の順序付きリスト

コード例:


						
1. Ordered list item
 
2. Ordered list item
 
3. Ordered list item

事例 3: ローマ数字の順序付きリスト

コード例:


						
i.   Ordered list item
 
ii.  Ordered list item
 
iii. Ordered list item
 
iv.  Ordered list item

事例 4: アルファベットの順序付きリスト

コード例:


						
A) Ordered list item
 
B) Ordered list item
 
C) Ordered list item

参考リソース

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

(今のところ、なし。)

検証

手順

テキストのコンテンツにあるリストに対して:

各リスト項目が、ラベルで始まる段落であることを確認する。
リスト項目ではない行が、リストに含まれていないことを確認する。
リストにあるリスト項目全てが、同じスタイルのラベルを用いていることを確認する。
順序付きリストのラベルが、連続した順序になっていることを確認する。
順不同リストのラベルが、同じであることを確認する。

期待される結果

上記の全ての結果が真である。

T3: 見出しに、標準的なテキストの書式の表現法を使用する

適用 (対象)

プレーンテキストのドキュメント。マークアップを含むウェブコンテンツ技術は対象外

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

解説

この達成方法の目的は、テキストの書式の規則を用いて、コンテンツの構造を伝えることである。見出しは、テキスト文書の各セクションの位置を示し、ラベル付けすることで、文書の構成を示すために用いられる。

見出しの始まりは、次のものによって示される。

見出しの前にある 2 行の空白行

見出しの終わりは、次のものによって示される。

見出しの後にある 1 行の空白行

空白行には、スペースやタブなどの印刷できない文字が任意の個数含まれていて、そのすぐ後に新しい行がある。

見出しのプログラム識別は、見出しの前の 2 行の空行と見出しの後の 1 行の空行である。テキストの文書では、文書構造として誤って解釈されうる要素をなくして、スクリーンリーダーのために文書構造をプログラムが解釈可能なレイアウトで示さなければならない。このプログラムが解釈可能なレイアウトによって、スクリーンリーダーが見出しであると考えられるテキストの前に空行を 2 回読み上げることができるようになる。画面拡大ソフトの利用者は、視覚的に空白があることによって、それが見出しであると解釈できる (または、画面拡大ソフトが空白を特定できるスクリーンリーダーの機能を併せ持っていることもある)。

事例

事例 1

段落の後に 2 行の空白行があり、それに続いて、見出し、1 行の空白行、そして次の段落がある:

コード例:


						
...this is the end of paragraph 1.


The Text of the Heading

This is the beginning of paragraph 2.

参考リソース

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

(今のところ、なし。)

検証

手順

コンテンツにあるそれぞれの見出しに対して:

見出しの前に、2 行の空白行があることを確認する。
見出しの後に、1 行の空白行があることを確認する。
見出しに空白行が含まれていないことを確認する。

期待される結果

上記の全ての結果が真である。

8. ARIA の達成方法

WAI-ARIA 技術ノート

WAI-ARIA は、アクセシビリティを向上させるために、ウェブページやリッチインターネットウィジェットに次のセマンティック情報を追加するオプションをウェブ開発者に提供する。その結果、そのセマンティック情報はブラウザに公開される。

"menu"、"treeitem"、"slider"、"progressbar" のような、提示されたウィジェットの種類を記述するためのロール。
見出し、領域、検索領域及びナビゲーション領域のような、ウェブページの構造を記述するためのロール。
チェックボックスのための "checked"、サブメニューやその他のポップアップを描画するメニューのための"haspopup"、及びツリーノードのための "expanded/collapsed" のような、ステート及びウィジェットを記述するためのプロパティ。
(たとえば株価情報のように) 情報が更新される予定があるページのライブ領域を定義するとともに、更新時の割込みポリシーを定義するためのプロパティ。支援技術は、重要な更新情報がレンダリングされたならすぐに提示してもよい。しかし、付随的な更新情報は、現在のタスクを完了した後のみに提示される。たとえば、スクリーンリーダーは、現在の段落を読み終えた後にのみ付随的な更新情報を利用者に通知する。
ドラッグソース及びドロップターゲットを記述するドラッグ＆ドロップのプロパティ。
リッチインターネットウィジェットにキーボードナビゲーションを提供するための方法。

これらの機能と DOM 構造によって伝えられる構造情報の組み合わせは、著者が支援技術に相互運用可能な解決策を作り出すことを可能にする。(出典: WAI-ARIA Overview)

WAI-ARIA に対するユーザエージェントのサポート

WAI-ARIA に対するユーザエージェントのサポートは変化するが、全般的な WAI-ARIA のサポートは改善している。WAI-ARIA をサポートするブラウザは、プラットフォームのアクセシビリティ API に WAI-ARIA ロール及びプロパティを対応づける。

Firefox 1.5 と Firefox 2.0 は部分的に WAI-ARIA をサポートするが、名前空間を使用する必要があり、ライブ領域の使用をサポートしない。
Firefox 3 以降はライブ領域を含む、WAI-ARIA に対するより良いサポートを含む。
IE8 は、部分的に WAI-ARIA をサポートする。
JAWS 8 及び Window-Eyes 5.5 以降は、部分的に WAI-ARIA をサポートする。
Jaws 10 以降は WAI-ARIA をサポートする。
Firefox の音声拡張である FireVox はまた、直接の DOM アクセスを経由して WAI-ARIA をサポートする。
NVDA は、部分的に WAI-ARIA をサポートする。

訳注: 「FireVox」は 2018 年現在、最新の Firefox と互換性がないためにインストールできない。

WAI-ARIA に対するアクセシビリティサポート

アクセシビリティサポーテッドな方法で技術を使用することは、適合性要求のために必要である。詳細はアクセシビリティサポートについてを読むこと。WCAG ワーキンググループは、Accessible Rich Internet Application 仕様が W3C 勧告の状態に到達する際に、WAI-ARIA 達成方法が十分であるかどうかの見直しをする予定である。WAI-ARIA のステータスに関する最新情報については、WAI-ARIA Overview を参照のこと。

ARIA1: ユーザインターフェースコントロールに対する説明ラベルを提供するために、aria-describedby プロパティを使用する

適用 (対象)

Accessible Rich Internet Applications (WAI-ARIA)をサポートするウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

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

ARIA1 に関するユーザエージェントサポートノートを参照のこと。WAI-ARIA 技術ノートも参照。

解説

この達成方法の目的は、プログラムによる解釈がされる、ユーザインタフェース要素に関する説明的な情報を提供するために、どのように WAI-ARIA aria-describedby プロパティを使用するかを示すことにある。aria-describedby プロパティは、ID 参照リストの使用を通して一つ以上の要素の説明的情報と結びつけるために使用してもよいものである。ID 参照リストは、一つ以上のユニークな要素 ID を含む。

XHTML や HTML とともに WAI-ARIA ステート及びプロパティを提供する方法については、Supporting ARIA in XHTML and HTML 4.01 を参照のこと。WAI-ARIA ステート及びプロパティは他の言語とも互換性がある。詳しくはそれらの言語の説明文書を参照のこと。

注記: aria-describedby プロパティは、外部リソース上の説明を参照するように設計されていない――これは ID なので、同一 DOM 文書内の要素を参照しなければならない。

訳注 1: 本文のリンク「Supporting ARIA in XHTML and HTML 4.01」は WAI-ARIA 1.0 Primer を参照しているが、この文書は作成が破棄されている。代わりに、WAI-ARIA 1.1 §A.6 HTML 4.01 plus WAI-ARIA DTD を参照できる。

訳注 2: XHTML 及び HTML 4.01 は廃止された勧告であることに注意されたい。

事例

事例 1: 「閉じる」ボタンの動作を記述するために aria-describedby プロパティを使用する

ダイアログ上の「閉じる」ボタンとして機能するボタンが、文書中の他の場所で説明されている。aria-describedby プロパティは、リンクと説明を関連付けるために使用される。

<button aria-label="Close" aria-describedby="descriptionClose"
    onclick="myDialog.close()">X</button>

...

<div id="descriptionClose">Closing this window will discard any information entered and
return you back to the main page</div>

実装例: 事例 1

事例 2: フォームフィールドと指示を関連付けるために aria-describedby を使用する

フォームフィールドに対してフォームラベルを用意するとともに、aria-describedby で指示を関連付けているサンプルフォームフィールド。

<form>
<label for="fname">First name</label>
<input name="" type="text" id="fname" aria-describedby="int2">
<p id="int2">A bit of instructions for this field linked with aria-describedby. </p>
</form>

事例 3: ボタンに関するより詳細な情報を提供するために aria-describedby プロパティを使用する

<p><span id="fontDesc">Select the font faces and sizes to be used on this page</span>
 <button id="fontB" onclick="doAction('Fonts');" aria-describedby="fontDesc">Fonts</button>
</p>
<p><span id="colorDesc">Select the colors to be used on this page</span>
 <button id="colorB" onclick="doAction('Colors');" aria-describedby="colorDesc">Colors</button>
</p>
<p><span id="customDesc">Customize the layout and styles used on this page</span>
 <button id="customB" onclick="doAction('Customize');" aria-describedby="customDesc">Customize</button>
</p>

事例 4: フォームフィールドとツールチップを関連付けるために aria-describedby を使用する

次のコードスニペットは、フォーカスが要素に置かれたときに、ツールチップを表示するために、aria-describedby と onfocus="tooltipShow()" 関数を使用する方法を示す。

<html lang="en-us">
<head>
   <title>inline: Tooltip Example 1</title>
   <link rel="stylesheet" href="css/tooltip1_inline.css" type="text/css">
   <script type="text/javascript" src="js/tooltip1_inline.js"></script>
   <script type="text/javascript" src="../js/widgets_inline.js"></script>
   <script type="text/javascript" src="../js/globals.js"></script>
   <link rel="icon" href="http://www.cites.uiuc.edu/favicon.ico" type="image/x-icon">
   <link rel="shortcut icon" href="http://www.cites.uiuc.edu/favicon.ico" type="image/x-icon">
</head>
   ...

<body onload="initApp()">

<div id="container">

<h1>Tooltip Example 1</h1>
<h2>Create Account</h2>
<div class="text">
<label for="first">First Name:</label>

<input type="text" id="first" name="first" size="20"
      onmouseover="tooltipShow(event, this, 'tp1');"
      onfocus="tooltipShow(event, this, 'tp1');"
      aria-describedby="tp1"
      aria-required="false"/>

<div id="tp1" role="tooltip" aria-hidden="true">Your first name is optional. </div>
</div>

事例 5: XHTML

この例は、XHTML でコーディングされ、application/xhtml+xml の MIME タイプで提供されている。このMIME タイプは、すべてのユーザエージェントでサポートされているわけではない。aria-describedby プロパティは、XHTML マークアップに直接追加され、追加のスクリプトを必要としない。

コード例:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+ARIA 1.0//EN"
"http://www.w3.org/WAI/ARIA/schemata/xhtml-aria-1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="content-type" content="application/xhtml+xml; charset=utf-8" />
<title>Demonstration of aria-describedby property</title>
<style type="text/css">
div.form p { clear:left; margin: 0.3em 0;}
.left {
  float:left;
  width:400px;
}
.right {
  width:100px;
  text-align:right;
}
</style>
</head>
<body>
<p>The buttons on this page use the Accessible Rich Internet Applications aria-describedby property
to provide more detailed information about the button action</p>
<div class="form">
<p><span class="left" id="fontDesc" >Select the font faces and sizes to be used on this page</span>
<span class="right"><button id="fontB" onclick="doAction('Fonts');" aria-describedby="fontDesc">
Fonts </button></span></p>
<p><span class="left" id="colorDesc" >Select the colors to be used on this page</span>
<span class="right"><button id="colorB" onclick="doAction('Colors');" aria-describedby="colorDesc">
Colors </button></span></p>
<p><span class="left" id="customDesc" >Customize the layout and styles used on this page</span>
<span class="right"><button id="customB" onclick="doAction('Customize');" aria-describedby="customDesc">
Customize </button></span></p>
</div>
</body>
</html>

事例 6: HTML

この例は、ページ上のボタンに aria-describedby プロパティを追加するためにスクリプトを使用している。この例は、説明テキストを含む要素の id を保持するために buttonIds 配列変数を作成する。setDescribedBy() 関数は、window オブジェクトの onload イベントから呼び出される。

setDescribedBy() 関数は、ボタン要素のすべてをループし、aria-describedby プロパティを設定するために各ボタン要素上で setAttribute() を呼び出す。各ボタンの aria-describedby プロパティは、その説明のテキストを含む要素の id に設定される。

WAI-ARIA をサポートするユーザエージェント及び／又は支援技術を使用すれば、ユーザインタフェースコントロールがフォーカスを受け取る際に説明が提供される。

コード例:

<html lang="en-us">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>Demonstration of aria-describedby property</title>
<style type="text/css">
div.form p { clear:left; margin: 0.3em 0;}
.left {
  float:left;
  width:400px;
}
.right {
  width:100px;
  text-align:right;
}
</style>
<script type="text/javascript">
//<![CDATA[

// array entries for each button on the page that associates the button id
// with the id of the element containing the text which describes the button
var buttonIds = new Array();
buttonIds["fontB"]= "fontDesc";
buttonIds["colorB"] = "colorDesc";
buttonIds["customB"] = "customDesc";

// function that is run after the page has loaded to set the aria-describedBy
// property on each of the elements referenced by the array of id values
function setDescribedBy(){
  if (buttonIds){
    var buttons = document.getElementsByTagName("button");
    if (buttons){
      var buttonId;
      for(var i=0; i<buttons.length; i++){
        buttonId = buttons[i].id;
        if (buttonId && buttonIds[buttonId]){
          buttons[i].setAttribute("aria-describedby", buttonIds[buttonId]);
        }
      }
    }
  }
}

// simulated action function - currently just displays an alert
function doAction(theAction){
  alert("Perform the " + theAction + " action");
}

window.onload=setDescribedBy;

//]]>
</script>
</head>
<body>
<p>The buttons on this page use the Accessible Rich Internet Applications
aria-describedby property to provide more detailed information
about the button action.
</p>
<div class="form">
<p><span class="left" id="fontDesc" >Select the font faces and sizes to be used on this page</span>
  <span class="right"><button id="fontB" onclick="doAction('Fonts');"> Fonts </button></span>
</p>
<p><span class="left" id="colorDesc" >Select the colors to be used on this page</span>
  <span class="right"><button id="colorB" onclick="doAction('Colors');"> Colors </button></span>
</p>
<p><span class="left" id="customDesc" >Customize the layout and styles used on this page</span>
  <span class="right"><button id="customB" onclick="doAction('Customize');"> Customize </button></span>
</p>
</div>
</body>

参考リソース

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

検証

手順

一意な ID を経由して一つ以上の要素を参照する aria-describedby 属性を持つユーザインタフェースコントロールがあることを確認する。
参照される要素 (一つ又は複数) が、ユーザインタフェースコントロールに関する追加情報を提供することを確認する。

期待される結果

1. 及び 2. の結果が真である。

ARIA2: aria-required プロパティによって必須項目を特定する

適用 (対象)

Accessible Rich Internet Applications (WAI-ARIA)をサポートするウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

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

ARIA2 に関するユーザエージェントサポートノートを参照のこと。WAI-ARIA 技術ノートも参照。

解説

この達成方法の目的は、(提示を通して必須であることが示されている) フォームフィールドが、フォームの正常送信のために必須であることを、プログラムの指標として提供することである。

要素が必須であるという事実は多くの場合、(テキスト又は非テキストのシンボル、又は入力が必須であることを示すテキスト、又は色/スタイルを介して) 視覚的に提示されるが、これは、フィールド名の一部としてプログラムによる解釈が可能にはならない。

WAI-ARIA aria-required プロパティは、送信前に利用者の入力が必須であることを示す。aria-required プロパティは、"true" 又は "false" の値を持つことができる。たとえば、利用者が住所のフィールドに入力しなければならない場合、aria-required は "true" に設定される。

注記 1: aria-required="true" の使用は、アスタリスクや他のテキストシンボルがプログラム的にフィールドに関連付けられている場合であっても、一部の支援技術の利用者に対して required プロパティによって補強できるので、有益であるかもしれない。

注記 2: 多くの場合、要素が必須であるという事実は、(コントロールの後の符号や記号のように) 視覚的に提示される。視覚的な提示に加えて aria-required プロパティを使用することは、ユーザエージェントが、この重要な情報をユーザエージェント固有の方法で利用者に伝えることを、はるかに簡単にする。XHTML や HTML とともに WAI-ARIA ステート及びプロパティを提供する方法については、Supporting ARIA in XHTML and HTML 4.01 を参照のこと。なお、WAI-ARIA ステート及びプロパティは他の言語とも互換性がある。詳しくはその言語における文書の活用を参照のこと。

訳注 1: 注記 2 にあるリンク「Supporting ARIA in XHTML and HTML 4.01」は WAI-ARIA 1.0 Primer を参照しているが、この文書は作成が破棄されている。代わりに、WAI-ARIA 1.1 §A.6 HTML 4.01 plus WAI-ARIA DTD を参照できる。

訳注 2: XHTML 及び HTML 4.01 は廃止された勧告であることに注意されたい。

事例

事例 1:

required プロパティが label 要素の後に置かれるアスタリスクによって示されている:


<form action="#" method="post"  id="login1" onsubmit="return errorCheck1()">
  <p>Note: [*]denotes mandatory field</p>
  <p>
    <label for="usrname">Login name: </label>
    <input type="text" name="usrname" id="usrname" aria-required="true"/>[*]
  </p>
  <p>
    <label for="pwd">Password</label>
    <input type="password" name="pwd" id="pwd" size="12" aria-required="true" />[*]
  </p>
  <p>
    <input type="submit" value="Login" id="next_btn" name="next_btn"/>
  </p>

</form>

事例 2:

required プロパティが label 要素の後に置かれる単語 "required" によって示されている:

<head>
<form action="#" method="post" id="step1" onsubmit="return errorCheck2()">
  <p>
    <label for="fname">First name: </label>
    <input type="text" id="fname" aria-required="true" />
    [required]
  </p>
  <p>
    <label for="mname">Middle name: </label>
    <input type="text" id="mname" />
  </p>
  <p>
    <label for="lname">Last name: </label>
    <input type="text" id="lname" aria-required="true" />
    [required]
  </p>
  <p>
    <label for="email">Email address: </label>
    <input type="text" id="email" aria-required="true" />
    [required]
  </p>
  <p>
    <label for="zip_post">Zip / Postal code: </label>
    <input type="text" id="zip_post" size="6" aria-required="true" />
    [required]
  </p>
  <p>
    <input type="submit" value="Next Step" id="step_btn" name="step_btn" />
  </p>
</form>

事例 3:

必須フィールドは、フィールドの周りの赤いボーダーと content:before を使用する CSS によってレンダリングされる星のアイコンで示される。この例はまた、role=radio をもつカスタムラジオボタンを使用するが、span を実際にラジオボタンのように動作させるためのスクリプトは、この例に含まれていない。CSS プロパティはフォームの下にある。


<form action="#" method="post" id="alerts1">
  <label for="acctnum" data-required="true">Account Number</label>
  <input size="12" type="text" id="acctnum"
      aria-required="true" name="acctnum" />

 <p id="radio_label" data-required="true">Please send an alert when balance exceeds $3,000.</p>

 <ul  id="rg" role="radiogroup" aria-required="true" aria-labelledby="radio_label">
    <li id="rb1" role="radio">Yes</li>
    <li id="rb2" role="radio">No</li>
 </ul>
</form>

この例に対する関連する CSS スタイル定義:


[aria-required=true] {
  border: red thin solid;
}
[data-required=true]:after {
  content: url('/iconStar.gif');
}

訳注: 説明に「content:before を使用する CSS によって」とあるが、コード例は :after となっており、説明とコードが矛盾している。

訳注: MDN の疑似要素 (Pseudo-elements) に示されているように、:after 疑似要素について、コロンを 1 個のみ用いるのは古い、互換性のための構文である。コロンを 2 個置くのが現在の正式な構文であることに注意されたい。

事例 4: XHTML における必須のテキスト入力フィールド

次の例は、フォームフィールドが送信されなければならないことを示すために aria-required プロパティを使用する XHTML 文書を示す。フィールドの必須の性質は、WAI-ARIA をサポートしないユーザエージェントのための予備として、ラベルでも表示される。

コード例:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1
    For Accessible Adaptable Applications//EN"
  "http://www.w3.org/WAI/ARIA/schemata/xhtml-aria-1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
          xml:lang="en">
  <head>
    <title>Required Input</title>
  </head>
  <body>
    <h1>Required Input</h1>
    <p>The following form input field must be completed by the user
    before the form can be submitted.</p>
    <form action="http://example.com/submit">
      <p>
        <label for="test">Test (required)</label>
        <input name="ariaexample" id="example" aria-required="true" aria-label="Test"/>
      </p>
      <p>
        <input type="submit" value="Submit" />
      </p>
    </form>
  </body>
</html>

事例 5: スクリプト経由で aria-required プロパティを追加する

この例は、フォーム要素に aria-required プロパティを追加するためにスクリプトを使用する。必須プロパティは、setAttribute() API を使用して割り当てられる。

配列変数 requiredIds は、必須としてマークされる必要がある要素の ID とともに作成される。setRequired() 関数は、window オブジェクトの onload イベントから呼び出される。

setRequired() 関数は、提供された ID のすべてをループし、要素を取得し、setAttribute() 関数を使用して aria-required プロパティを true にする。

このページが Firefox 3.0 以降及び WAI-ARIA をサポートするスクリーンリーダーを使用してアクセスされる場合、入力フィールドのラベルを読む際にスクリーンリーダーは "required" と伝える。

コード例:

<head>
 <script type="text/javascript">
 //<![CDATA[

 // array or ids on the required fields on this page
 var requiredIds = new Array( "firstName", "lastName");

 // function that is run after the page has loaded to set the aria-required property on each of the
 //elements in requiredIds array of id values
 function setRequired(){
 	if (requiredIds){
 		var field;
 		for (var i = 0; i< requiredIds.length; i++){
 			field = document.getElementById(requiredIds[i]);
 			field.setAttribute("aria-required", "true");
 		}
 	}
 }
 window.onload=setRequired;
//]]>
 </script>
 </head>
 <body>
 <p>Please enter the following data.  Required fields have been programmatically identified
 as required and  marked with an asterisk (*) following the field label.</p>
 <form action="submit.php">
 <p>
 <label for="firstName">First Name *: </label><input type="text" name="firstName"
    id="firstName" value="" />
 <label for="lastName">Last Name *: </label><input type="text" name="lastName"
    id="lastName"  value="" />
 </p>
 </form>
 </body>

参考リソース

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

検証

手順

必須であることがプレゼンテーションを経由して示される各コントロールに対して。

aria-required 属性が存在するかどうかを確認する:
aria-required 属性値が、そのユーザインタフェースコンポーネントに対する正しい required ステートであるかどうかを確認する。

期待される結果

1. 及び 2. の結果が真である。

ARIA4: ユーザインターフェースコンポーネントの役割 (role) を明示するために、WAI-ARIA ロールを使用する

適用 (対象)

Accessible Rich Internet Applications (WAI-ARIA)をサポートするウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- クイックリファレンス 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- 達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )を理解する

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

ARIA4 に関するユーザエージェントサポートノートを参照のこと。WAI-ARIA 技術ノートも参照。

解説

この達成方法の目的は、WAI-ARIA Definition of Roles で定義されたいずれかの非抽象の値を持つ role 属性を用いて要素のロールを定義することである。WAI-ARIA 仕様は、各ロールについて、他のロールとどのように関係するか、どのようなステート及びプロパティがあるかといった、参考となる説明を提供している。リッチインターネットアプリケーションが新しいユーザインタフェースウィジェットを定義する際、ロールを公開することで、利用者がウィジェット及びウィジェットと対話する方法を理解できるようになる。

事例

事例 1: 単純なツールバー

WAI-ARIA Authoring Practices には、三つのボタンを含むツールバーのデモがある。div 要素は "toolbar" のロールを持ち、img 要素は "button" のロールを持つ:


    <div role="toolbar"
      tabindex="0" 
      id="customToolbar" 
      onkeydown="return optionKeyEvent(event);"
      onkeypress="return optionKeyEvent(event);"
      onclick="return optionClickEvent(event);"
      onblur="hideFocus()"
      onfocus="showFocus()"
      > 
      <img src="img/btn1.gif" 
           role="button" 
           tabindex="-1" 
           alt="Home" 
           id="b1" 
           title="Home">
      <img src="img/btn2.gif" 
           role="button" 
           tabindex="-1" 
           alt="Refresh" 
           id="b2" 
           title="Refresh">
     <img src="img/btn3.gif" 
           role="button" 
           tabindex="-1" 
           alt="Help" 
           id="b3" 
           title="Help"> 
 </div>

Authoring Practices のツールバーパターンは、ツールバーの実装例を提供している。

事例 2: ツリーウィジェット

WAI-ARIA Authoring Practices には、ツリーウィジェットのデモがある。ツリーとその構造を識別するためのロール "tree"、"treeitem"、"group" に注意。コードを単純化して抜粋したものは以下のとおり:


<ul role="tree" tabindex="0">
  <li role="treeitem">Birds</li>
  <li role="treeitem">Cats
    <ul role="group">
      <li role="treeitem">Siamese</li>
      <li role="treeitem">Tabby</li>
    </ul>
  </li>
  <li role="treeitem">Dogs
    <ul role="group">
      <li role="treeitem">Small Breeds
        <ul role="group">
          <li role="treeitem">Chihuahua</li>
          <li role="treeitem">Italian Greyhound</li>
          <li role="treeitem">Japanese Chin</li>
        </ul>
      </li>
      <li role="treeitem">Medium Breeds
        <ul role="group">
          <li role="treeitem">Beagle</li>
          <li role="treeitem">Cocker Spaniel</li>
          <li role="treeitem">Pit Bull</li>
        </ul>
      </li>
      <li role="treeitem">Large Breeds
        <ul role="group">
          <li role="treeitem">Afghan</li>
          <li role="treeitem">Great Dane</li>
          <li role="treeitem">Mastiff</li>
        </ul>
      </li>
    </ul>
  </li>
</ul>

Authoring Practices のツリービューパターンは、ツリーの実装例を提供している。

参考リソース

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

訳注: 「WAI-ARIA 1.1 Authoring Practices」は、正しくは「WAI-ARIA Authoring Practices 1.1」となる。

(今のところ、なし。)

検証

手順

role 属性を使用するユーザインタフェースコンポーネントの場合:

role 属性の値が、WAI-ARIA 仕様で定義された値に由来する非抽象ロールのいずれかであることを確認する。
ユーザインタフェースコンポーネントの特性がロールで記述されていることを確認する。

期待される結果

1. 及び 2. の結果が真である。

ARIA5: ユーザインターフェースコンポーネントの状態 (state) を明示するために、WAI-ARIA ステート及びプロパティ属性を使用する

適用 (対象)

Accessible Rich Internet Applications (WAI-ARIA)をサポートするウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- クイックリファレンス 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- 達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )を理解する

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

ARIA5 に関するユーザエージェントサポートノートを参照のこと。WAI-ARIA 技術ノートも参照。

解説

この達成方法の目的は、ユーザインタフェースコンポーネントのステート、プロパティ及び値を公開するために WAI-ARIA ステート及びプロパティを使用することであり、その結果それらが支援技術によって読み込まれて設定できるようになり、また、支援技術はそれらの値の変更を通知される。WAI-ARIA 仕様は、各属性の規範的記述、及びユーザインタフェース要素がサポートするロールを提供する。リッチインターネットアプリケーションが新しいユーザインタフェースウィジェットを定義する際、ステート及びプロパティ属性を公開することで、利用者がウィジェットを理解でき、そしてウィジェットと対話できるようになる。

事例

事例 1: トグルボタン

button ロールを持つウィジェットが aria-pressed 属性を実装する場合、トグルボタンとして動作する。aria-pressed が true である場合、ボタンは「押されている」状態になる。aria-pressed が false である場合、押されていないことになる。この属性が存在しない場合、ボタンは単純なコマンドボタンとなる。

以下のスニペットは Open Ajax Accessibility Examples の例 38 からの引用であり、太字のテキストを選択するトグルボタンに対する WAI-ARIA マークアップを示している:


  <li id="bold1"  
    class="toggleButton"
    role="button"
    tabindex="0"
    aria-pressed="false"
    aria-labelledby="bold_label"
    aria-controls="text1">
    <img src="http://www.oaa-accessibility.org/media/examples/images/button-bold.png" alt="bold text" align="middle">
</li>

この li 要素は、"button" ロールと "aria-pressed" 属性を持つ。以下は、この例において "aria-pressed" 属性の値を更新する Javascript の抜粋である:

                   
                             /**
   * togglePressed() toggles the aria-pressed atribute between true or false
   *
   * @param ( id object) button to be operated on
   *
   * @return N/A
   */
  function togglePressed(id) {
  
    // reverse the aria-pressed state
    if ($(id).attr('aria-pressed') == 'true') {
      $(id).attr('aria-pressed', 'false');
    }
    else {
      $(id).attr('aria-pressed', 'true');
    }
  }

このボタンは、OpenAjax アライアンスのサイトで、working example of Example 38 - Toolbar using inline images for visual state の実装例の一部として提供されている。

事例 2: スライダー

slider ロールをもつウィジェットは、利用者に指定した範囲内から値を選択させる。スライダーは、スライダーの大きさやつまみの位置によって、現在の値、及びとり得る値の範囲を表す。これらのスライダーのプロパティは、属性 aria-valuemin、aria-valuemax、及び aria-valuenow で表される。

以下のスニペットは Open Ajax Accessibility Examples の例 32 からの引用であり、JavaScript で作成されたスライダーに対する WAI-ARIA マークアップを示している。Javascript が属性 aria-valuemin、aria-valuemax、及び aria-valuenow を設定することに注意:

   var handle = '<img id="' + id + '" class="' + (this.vert == true ? 'v':'h') +'sliderHandle" ' +
    'src="http://www.oaa-accessibility.org/media/examples/images/slider_' + (this.vert == true ? 'v':'h') + '.png" ' + 'role="slider" ' +
    'aria-valuemin="' + this.min +
    '" aria-valuemax="' + this.max +
    '" aria-valuenow="' + (val == undefined ? this.min : val) +
           '" aria-labelledby="' + label +
           '" aria-controls="' + controls + '" tabindex="0"></img>';

以下はこの例のための Javascript の抜粋であり、スライダーのつまみの値が変更された場合に "aria-valuenow" 属性値を更新する:

 slider.prototype.positionHandle = function($handle, val) {
    ...
   // Set the aria-valuenow position of the handle
  $handle.attr('aria-valuenow', val);
   ...
  }

このスライダーは、OpenAjax アライアンスのサイトで、working example of Example 32 - Slider の実装例の一部として提供されている。

参考リソース

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

検証

手順

The WAI-ARIA specification, Section 5.3, Categorization of Roles は、各ロールに対し、必須であったり、継承されたりするステート及びプロパティを定義している。

WAI-ARIA role 属性を使用するユーザインタフェースコンポーネントの場合:

ロールに対して必須とされるステート及びプロパティが存在することを確認する。
必須でなく、サポートもされず、継承もされない WAI-ARIA ステート又はプロパティが存在しないことを確認する。
ユーザインタフェースコンポーネントが状態を変更するときに、ステート及びプロパティの値が現在の状態を反映するように更新されていることを確認する。

期待される結果

1.、2. 及び 3. の結果が真である。

ARIA6: オブジェクトのラベルを提供するために aria-label を使用する

適用 (対象)

Accessible Rich Internet Applications (WAI-ARIA)をサポートするウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

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

ARIA6 に関するユーザエージェントサポートノートを参照のこと。WAI-ARIA 技術ノートも参照。

解説

この達成方法の目的は、支援技術によって読み取ることができるオブジェクトのラベルを提供することである。aria-label 属性は、ボタンなど、オブジェクトのテキストラベルを提供する。スクリーンリーダーがオブジェクトに遭遇した際、aria-label テキストが読み込まれ、利用者はそのオブジェクトがどのようなものかを知ることができる。

制作者は、aria-labelledby が同じオブジェクトに使用される状況では、aria-label が支援技術によって無視される場合があることに注意すべきである。名前付けの序列の詳細については、ARIA 仕様及び HTML to Platform Accessibility APIs Implementation Guide における accessible name and description calculation を参照。制作者は、aria-label の使用が画像の alt や for 属性を用いてフォームフィールドに関係付けられた label などのネイティブな名前付けを全て上書きすることに注意すべきである。

事例

事例 1: ナビゲーションランドマークを区別する

次の例は、同じページに同じ種類のランドマークが 2 個以上存在し、かつページ内にラベルとして参照できる既存のテキストが存在しない場合に、HTML4 及び XHTML 1.0 文書内で二つのナビゲーションランドマークを識別するために aria-label をどのように使用するのかを示している。

訳注: HTML4 及び XHTML 1.0 は Superseded Recommendation としてマークされ、廃止された仕様である。

<div role="navigation" aria-label="Primary">
<ul><li>...a list of links here ...</li></ul> </div>
<div role="navigation" aria-label="Secondary">
<ul><li>...a list of links here ...</li> </ul></div>

事例 2: 領域のランドマークを識別する

次の例は、気象ポートレットに一般的な "region" ランドマークがどのように追加されうるのかを示している。ラベルとして参照できる既存のテキストがページ内に存在しないため、aria-label でラベル付けされている。

<div role="region" aria-label="weather portlet"> 
...
</div>

事例 3: 数学のラベルを提供する

以下は math ロール、適切なラベル、および MathML レンダリングを使用する、MathML の機能の例である。

<div role="math" aria-label="6 divided by 4 equals 1.5">
  <math xmlns="http://www.w3.org/1998/Math/MathML">
    <mfrac>
      <mn>6</mn>
      <mn>4</mn>
    </mfrac>
    <mo>=</mo>
    <mn>1.5</mn>
  </math>
</div>

参考リソース

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

検証

手順

aria-label 属性が存在する各要素に対して。

テキストの説明が正確にオブジェクトをラベル付けする、又はその目的の説明を提供する、又は同等の情報を提供するかどうかを検査する。

期待される結果

1. の結果が真である。

ARIA7: リンクの目的を示すために aria-labelledby を使用する

適用 (対象)

Accessible Rich Internet Applications (WAI-ARIA)をサポートするウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.4 (リンクの目的 (コンテキスト内) )
- クイックリファレンス 2.4.4 (リンクの目的 (コンテキスト内) )
- 達成基準 2.4.4 (リンクの目的 (コンテキスト内) )を理解する

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

ARIA7 に関するユーザエージェントサポートノートを参照のこと。WAI-ARIA 技術ノートも参照。

解説

aria-labelledby 属性を用いることで、制作者は、ページ上の可視テキスト要素を、フォーカス可能な要素 (フォームコントロール又はリンク) のラベルとして使用できる。たとえば、"read more..." のリンクは、リンクの目的を明確にするために、先行するセクションの見出しテキストと関連付けることができるかもしれない (事例 1 を参照)。

aria-labelledby の助けを借りてフォーカス可能な要素にテキストを関連付ける場合、ターゲットのテキスト要素は、フォーカス可能な要素の aria-labelledby 属性値の中で参照される ID によって与えられる。

フォーカス可能な要素のラベルとして、ページ上の複数のテキスト要素を使用することも可能である。使用されるそれぞれのテキスト要素は、aria-labelledby 属性の値において IDs (IDREF) の文字列として参照される一意な ID を与えられなければならない。そして、ラベルテキストは aria-labelledby 属性の値における ID の順序に従って連結されるべきである。

リンクに適用する場合、aria-labelledby は、目の見える利用者に対して直ちに明白かもしれないが、スクリーンリーダーの利用者にはあまり明らかではないリンクの目的を識別するために使用できる。

aria-labelledby の仕様上の動作は、関連付けられたラベルテキストが (リンクテキストに加えられるのではなく) リンクテキストの代わりに告知されるものである。リンクテキスト自身がラベルテキストに含まれるべきである場合、aria-labelledby 属性の値を構成する IDs の文字列の中で、リンクの ID も参照されるべきである。

名前付けの序列の詳細については、ARIA specification 及び HTML to Platform Accessibility APIs Implementation Guide における accessible name and description calculation for links を参照。

事例

事例 1: リンクに追加情報を提供する

この例は、画面に表示されるリンクテキストが、リンクに対するアクセシブルな名前の最初に使用されることを意図している。JAWS や NVDA のようなポピュラーなスクリーンリーダーは、これを "Read more ...Stormshit east coast" のように告知し、リンクだけを閲覧することがあるスクリーンリーダーの利用者にとって有益なリンク一覧にも同じテキストを表示する。

<h2 id="headline">Storms hit east coast</h2>

<p>Torrential rain and gale force winds have struck the east coast, causing flooding in many coastal towns.
<a id="p123" href="news.html" aria-labelledby="p123 headline">Read more...</a></p>

事例 2: 複数のソースからのリンクテキストを連結する

制作者は、参照したいコードのセクションを囲むタグを配置することもあるだろう。

注記: span 要素上の tabindex="-1" の使用は、スクリプトによってフォーカスをサポートすることを意味するものではない――ここでは、単に一部のブラウザ (IE9、IE10) がアクセシビリティツリーに span 要素を含めることを保証するためのものであり、その結果、aria-labelledby による参照に利用できるようになる。詳細については、Accessible HTML Elements を参照。

<p>Download <span id="report-title" tabindex="-1">2012 Sales Report</span>:
<a aria-labelledby="report-title pdf" href="#" id="pdf">PDF</a> |
<a aria-labelledby="report-title doc" href="#" id="doc">Word</a> |
<a aria-labelledby="report-title ppt" href="#" id="ppt">Powerpoint</a></p>

参考リソース

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

HTML to Platform Accessibility APIs Implementation Guide: Accessible Name and Description Calculation

(今のところ、なし。)

検証

手順

aria-labelledby 属性を持つ各リンクに対して:

aria-labelledby 属性の値に含まれる各 ID が、リンクの目的の一部として使用されるテキスト要素の ID と一致することを確認する。
aria-labelledby 属性に含まれる一つ以上の ID によって参照されるテキストを合成した値が、link 要素の目的を適切に説明していることを確認する。

期待される結果

1. 及び 2. の結果が真である。

ARIA8: リンクの目的を示すために aria-label を使用する

適用 (対象)

Accessible Rich Internet Applications (WAI-ARIA) をサポートするウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

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

ARIA8 に関するユーザエージェントサポートノートを参照のこと。WAI-ARIA 技術ノートも参照。

解説

この達成方法の目的は、aria-label 属性を使用して、リンクの目的を説明することである。オブジェクトを説明する可視要素がページ上に存在しない場合、aria-label 属性は、リンクのようなオブジェクトに説明的なテキストラベルを配置する方法を提供する。説明的な要素がページ上で可視である場合、aria-label ではなく、aria-labelledby 属性が使用されるべきである。説明的なテキストラベルを提供することで、利用者は、そのリンクと、ウェブページ内にあるリンク先の異なるリンクとを区別できるようになり、リンクをたどるかどうかを判断する助けとなる。一部の支援技術において、aria-label の値は、実際のリンクテキストの代わりにリンクの一覧に表示される。

WAI-ARIA 仕様及び HTML to Platform Accessibility APIs Implementation Guide にあるように、aria-label テキストは、リンク内で与えられたテキストを上書きする。このように与えられたテキストは、支援技術によってリンクテキストの代わりに使用される。このため、aria-label で使用されるテキストは、リンク内で使用されているテキストから始めることが推奨されている。これは、利用者間で一貫性のあるコミュニケーションを可能にする。

事例

事例 1: aria-label を使用して、HTML 内のリンクの目的を説明する

場合によっては、デザイナーが、ページ上のリンクの見た目をコンパクトにするために、"read more" のような短く、繰り返されるリンクテキストを選択することがある。こういった状況は、より単純で非説明的な "read more" というページ上のテキストを、より説明的なリンクのラベルで置き換えることができるという点で、aria-label の望ましいユースケースとなる。単語 "read more" は、利用者間の一貫性のあるコミュニケーションを可能にするために (元のアンカーテキスト "[Read more...]" を置き換える) aria-label の中にも繰り返される。

 <h4>Neighborhood News</h4>
 <p>Seminole tax hike:  Seminole city managers are proposing a 75% increase in 
 property taxes for the coming fiscal year.
 <a href="taxhike.html" aria-label="Read more about Seminole tax hike">[Read more...]</a>
 </p> 

 <p>Baby Mayor:  Seminole voters elect the city's youngest mayor ever by voting in 3 year
 old Willy "Dusty" Williams in yesterday's mayoral election.
 <a href="babymayor.html" aria-label="Read more about Seminole's new baby mayor">[Read more...]</a>
 </p>

参考リソース

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

検証

手順

aria-label 属性を使用するリンク要素に対して:

aria-label 属性の値が link 要素の目的を正確に説明していることを確認する。

期待される結果

1. の結果が真である。

ARIA9: 複数のテキストノードをつなげて一つのラベルにするために、aria-labelledby を使用する

適用 (対象)

Accessible Rich Internet Applications (WAI-ARIA) をサポートするウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

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

ARIA9 に関するユーザエージェントサポートノートを参照のこと。WAI-ARIA 技術ノートも参照。

解説

aria-labelledby プロパティは、すべての視覚的オブジェクトをラベル付けするために使用できる。入力に適用する場合、aria-labelledby プロパティは、div contenteditable="true" によって構築されるカスタムテキスト入力のような非ネイティブ要素だけでなく、ネイティブの入力に対するラベル付けにも利用することができる。

aria-labelledby の特有の用途のひとつは、意味のあるラベルが複数のラベル文字列から構成される状況における、テキスト入力のためのものである。

制作者は、input 要素のラベルとして連結されるために、ラベル文字列に一意の id を割り当てる。aria-labelledby 属性の値は、参照されたラベル文字列がスクリーンリーダーで読みあげられるべき順序に並べられた、全 id のスペース区切りのリストである。サポートするユーザエージェントは、参照されたラベル文字列を連結して、入力欄の一つの連続したラベルとして読みあげる。

ラベル文字列の連結は、さまざまな理由で便利である。事例 1 において、入力欄は完全な一文のコンテキスト内に含まれている。望ましいスクリーンリーダーの出力は、"Extend time-out to [ 20 ] minutes - edit with autocomplete, selected 20" である。テキスト入力の id は aria-labelledby で参照される id の文字列に含まれているので、入力の値は連結されたラベルの正しい位置に含まれる。

aria-labelledby の別の応用は、入力欄の隣に視覚的なラベルを提供するためのスペースが存在しない場合、又はネイティブラベルの使用が不必要な冗長性を生む場合である。このとき、aria-labelledby を使用すると、ページ上の可視要素をそのような入力のラベルとして関連付けることができる。この方法は事例 2 において示されており、テーブルの列及び行の見出しが連結されて、テーブル内部のテキスト入力要素のラベルとなっている。

注記: ARIA accessible name and description calculation は、aria-labelledby で指定された文字列が、プロパティを有する要素のコンテンツに追加されるのではなく、置換するべきと規定している。よって、aria-labelledby プロパティをネイティブラベルに追加する場合、ラベル自体が aria-labelledby の id のシーケンスの一部として参照されていない限り、そのラベル内のテキストコンテンツが置換されるべきである。

事例

事例 1: 連結されたラベルをもつタイムアウト入力フィールド

テキスト入力欄があり、タイムアウトが発生する前に、利用者がデフォルトの時間を延長することを可能にしている。

文字列 "Extend time-out to" は、ネイティブの label 要素に含まれており、id="timeout-duration" により入力に関連付けられる。このラベルは、ARIA をサポートしないユーザエージェント上においてのみ、for/id 関連付けを使用してこの入力に関連付けられる。ARIA をサポートするユーザエージェント上では、for/id 関連付けは無視され、入力用のラベルは、HTML to Platform Accessibility APIs Implementation Guide における accessible name and description calculation に従って、aria-labelledby のみによって提供される。

テキスト入力上の aria-labelledby 属性は、三つの要素を参照する: (1) ネイティブのラベルを含む span、(2) デフォルトテキスト'20'を含むテキスト入力 (この入力が、ラベルテキストに関連する for/id でラベル付けされないことを思い起こすこと)、(3) span に含まれる文字列 'minutes'。これらの要素は、テキスト入力に対する完全なラベルを提供するために連結されるべきである。

<form>
<p><span id="timeout-label" tabindex="-1"><label for="timeout-duration">Extend time-out to</label></span>
<input type="text" size="3" id="timeout-duration" value="20" 
    aria-labelledby="timeout-label timeout-duration timeout-unit">
<span id="timeout-unit" tabindex="-1"> minutes</span></p>
</form>

実装例連結されたラベルをもつタイムアウト入力フィールドは、Marco Zeheによってまとめられた Easy ARIA tip #2: aria-labelledby and aria-describedby から翻案した。

事例 2: テキスト入力を含む単純なデータテーブル

テキスト入力を含む単純なデータテーブルがある。入力ラベルは、それぞれの列及び行のヘッダーを参照する aria-labelledby を通して連結される。

<table>
	<tr>
		<td></td>
		<th id="tpayer">Taxpayer</th>
		<th id="sp">Spouse</th>
	</tr>

	<tr>
		<th id="gross">W2 Gross</th>
		<td><input type="text" size="20" aria-labelledby="tpayer gross" /></td>
		<td><input type="text" size="20" aria-labelledby="sp gross" /></td>
	</tr>
	
	<tr>
		<th id="div">Dividends</th>
		<td><input type="text" size="20" aria-labelledby="tpayer div" /></td>
		<td><input type="text" size="20" aria-labelledby="sp div" /></td>
	</tr>
</table>

実装例テキスト入力をもつ単純なテーブルに対する aria-labelledby を使用するは、Jim Thatcher による例に基づく。

事例 3: 会議ワークショップ予約テーブル

二つの同時進行のトラックをもつ会議ワークショップ予約テーブルがあり、利用者が参加したいワークショップを選択することを可能にしている。テーブル内のチェックボックス入力の間をタブ移動するとき、トラック (1 又は 2)、タイトル、及び隣接するチェックボックスのラベル "Attend" に続くワークショップのスピーカーは、aria-labelledby を介してチェックボックスに対する連結ラベルとして提供される。

一部のブラウザ/スクリーンリーダーの組み合わせ (たとえば Mozilla Firefox と NVDA) は、さらに関連するテーブルセルのヘッダーを伝える。

<h1>Dinosaur Conference workshops timetable Thursday, 14.  & Friday, 15. March 2013</h1>
<table>
<caption>Dinosaur Conference workshop booking table</caption>
<tbody><tr>
	<td rowspan="2"></td>
	<th colspan="2" scope="colgroup">Thursday</th>
	<th colspan="2" scope="colgroup">Friday</th>
</tr>

<tr>
	<th scope="col" id="am1">9 to 12 AM</th>
	<th scope="col" id="pm1">2 to 5 PM</th>
	<th scope="col" id="am2">9 to 12 AM</th>
	<th scope="col" id="pm2">2 to 5 PM</th>
</tr>

<tr>
	<th id="track1" scope="row">track 1</th>
	<td>
		<h2 id="title-TM1">The Paleozoic era </h2>
		<p>2 places left</p>
		<p><input type="checkbox" id="TM1" aria-labelledby="title-TM1 track1 am1 TM1-att">
                <label id="TM1-att" for="TM1">Attend</label></p>
	</td>
	
	<td>
		<h2 id="title-TA1">The Mesozoic era overview</h2>
		<p>2 places left</p>
		<p><input type="checkbox" id="TA1" aria-labelledby="title-TA1 track1 am2 TA1-att">
                <label id="TA1-att" for="TA1">Attend</label></p>
	</td>
	
	<td>
		<h2 id="title-FM1">The Triassic period, rise of the dinosaurs</h2>
		<p>1 place left</p>
		<p><input type="checkbox" id="FM1" aria-labelledby="title-FM1 track1 pm1 FM1-att">
                <label id="FM1-att" for="FM1">Attend</label></p>

	</td>
	
	<td>
		<h2 id="title-FA1">The Jurassic period</h2>
		<p>11 places left</p>
		<p><input type="checkbox" id="FA1" aria-labelledby="title-FA1 track1 pm2 FA1-att">
                <label id="FA1-att" for="FA1">Attend</label></p>
	</td>
</tr>


<tr>
	<th id="track2" scope="row">track 2</th>
	<td>
		<h2 id="title-TM2">The Cretaceous period</h2>
		<p>18 places left</p>
		<p><input type="checkbox" id="TM2" aria-labelledby="title-TM2 track2 am1 TM2-att">
                <label id="TM2-att" for="TM2">Attend</label></p>
	</td>
	
	<td>
		<h2 id="title-TA2">The end of the dinosaurs</h2>
		<p>2 places left</p>
		<p><input type="checkbox" id="TA2" aria-labelledby="title-TA2 track2 am2 TA2-att">
                <label id="TA2-att" for="TA2">Attend</label></p>
	</td>
	
	<td>
		<h2 id="title-FM2">First discoveries of dinosaurs</h2>
		<p>2 places left</p>
		<p><input type="checkbox" id="FM2" aria-labelledby="title-FM2 track2 pm1 FM2-att">
                <label id="FM2-att" for="FM2">Attend</label></p>
	</td>
	
	<td>
		<h2 id="title-FA2">Emerging scholarship</h2>
		<p>19 places left</p>
		<p><input type="checkbox" id="FA2" aria-labelledby="title-FA2 track2 pm2 FA2-att">
                <label id="FA2-att" for="FA2">Attend</label></p>
	</td>
</tr>
</tbody>
</table>

実装例: 会議ワークショップ予約時間表

参考リソース

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

HTML to Platform Accessibility APIs Implementation Guide: Accessible Name and Description Calculation
WAI-ARIA Authoring Practices 1.1
Using WAI-ARIA in HTML: Section 2.7 aria-labelledby and aria-describedby

検証

手順

aria-labelledby を使用する入力に対して:

aria-labelledby で参照される id が一意であり、かつ組み合わせてラベルを提供するテキストノードの id と一致することを確認する
aria-labelledby によって参照される要素を連結したコンテンツが、ラベル付けされた要素の目的又は機能に対する説明であることを確認する

期待される結果

1. 及び 2. の結果が真である。
これが達成基準に対して十分な達成方法である場合、このテスト手順を失敗しても、この達成方法がうまく実装されず適合性を主張するために使用できないだけであり、達成基準が他の方法で満たされていないことを必ずしも意味するものではない。

ARIA10: 非テキストコンテンツに対してテキストによる代替を提供するために aria-labelledby を使用する

適用 (対象)

Accessible Rich Internet Applications (WAI-ARIA) を用いる HTML。

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

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

ARIA10 に関するユーザエージェントサポートノートを参照のこと。WAI-ARIA 技術ノートも参照。

解説

この達成方法の目的は、aria-labelledby 属性を使用することで支援技術 (AT) によって読み取ることのできる要素に対する短い説明を提供することである。aria-labelledby 属性は、ラベル付けする要素の ID 属性とマッチする ID 参照値を使用することで、ページ上のどこかで可視になっているテキストと要素とを関連づける。スクリーンリーダーのような支援技術は、aria-labelledby 属性値によって特定される要素のテキストを、その属性をもつ要素に対するテキストによる代替として使用する。

事例

事例 1: 複雑な図形に短い説明を提供する

この例は、図形が複数の画像要素から構成されている読み取り専用の星評価パターンに対して、どのように aria-labelledby 属性を用いて短いテキストの説明を提供するのかを示している。図形に対するテキストによる代替はラベルであり、ページ内の星パターンのすぐ下に見える形で置かれている。

<div role="img" aria-labelledby="star_id">
<img src="fullstar.png" alt=""/>
<img src="fullstar.png" alt=""/>
<img src="fullstar.png" alt=""/>
<img src="fullstar.png" alt=""/>
<img src="emptystar.png" alt=""/>
</div>

<div id="star_id">4 of 5</div>

実装例: 複雑な図形に短い説明を提供する

参考リソース

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

検証

手順

aria-labelledby 属性が存在してかつ要素が alt 属性をサポートしない場合に各要素を検査する。
aria-labelledby 属性値がウェブページ上の要素の id であることを確認する。
aria-labelledby 属性によって特定される要素のテキストが、正確に要素をラベル付けする、又はその目的の説明を提供する、又は同等の情報を提供することを判断する

期待される結果

2. 及び 3. の結果が真である。

ARIA11: ページのリージョンを特定するために ARIA ランドマークを使用する

適用 (対象)

Accessible Rich Internet Applications (WAI-ARIA) をサポートするウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

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

ARIA11 に関するユーザエージェントサポートノートを参照のこと。WAI-ARIA 技術ノートも参照。

解説

この達成方法の目的は、ウェブページのセクションに対して、プログラムによるアクセスを提供することである。ランドマークロール (又はランドマーク) は、ページのセクションをプログラムによって識別できるようにする。ランドマークは、支援技術 (AT) 利用者がページに順応するのを支援し、様々なページのセクションにより簡単にナビゲートするのに役立つ。

ランドマークはまた、支援技術の利用者に、複数ページで繰り返されるコンテンツのブロックをスキップする容易な方法を提供するとともに、ページの構造をプログラムによって理解できるようにする。たとえば、すべてのページに見られる共通のナビゲーションメニューが存在する場合、ランドマークロール (又はランドマーク) は、ナビゲーションメニューをスキップし、セクションからセクションにナビゲートするために使用できる。これは、伝統的な「スキップリンク」メカニズムそっくりに、支援技術利用者とキーボード利用者が、実際に後続にあるものを見つけるために大量のコンテンツの中をタブ移動するための時間と手間を省く (支援技術サポートの詳細については上記のユーザエージェントノートを参照のこと)。ニュースサイトのメニューに精通しているだろう、トップニュースを得ることにのみ関心がある目の不自由な利用者は、より容易に "main" ランドマークにナビゲートして、多数のメニューリンクを無視できる。別の状況で、目の不自由な利用者は、すぐにナビゲーションメニューを検索したいかもしれず、ナビゲーションランドマークにジャンプすることでこれを実現できる。

ランドマークはまた、目の見えるキーボード利用者がブラウザプラグインを使用して、ページのセクションにナビゲートするのを支援することもできる。

ランドマークは、セクションをマークする要素上の role 属性を使用してページに挿入される。属性値は、ランドマークの名前である。ロールの値は次のとおりである:

banner: ページの主見出し又は内部タイトルを含む領域。
complementary: 主要コンテンツをサポートしているが、独立しかつ意味のある、文書の任意のセクション。
contentinfo: 著作権やプライバシーに関する声明へのリンクなど、親文書に関する情報を含む領域。
form: フォーム関連要素のコレクションを表す文書の領域であり、その一部は編集可能な、処理するためにサーバーに送信可能な値を表すことができる。
main: 文書における主要コンテンツ。ほとんどの場合において、一つのページは一つのみの role="main" を持つ。
navigation: 文書内の、又は関連する文書へのナビゲートに適したリンクのコレクション。
search: ウェブ文書の検索ツール。
application: ウェブ文書とは対照的な、ウェブアプリケーションとして宣言された領域。(注記: application ロールは、スクリーンリーダーに対して通常のウェブナビゲーションコントロールをオフにする信号を与えるため、注意して使用すべきである。一般に、単純なウィジェットには application ロールを与えるべきでなく、また、全くウェブページのように利用されておらず、かつ支援技術を用いた利用者のテストが十分に行われている場合を除き、ウェブページの全体に application ロールを与えるべきではない。)

訳注: HTML5 において、上記のロールは代わりに HTML 要素を使うことでランドマークを支援技術に伝達できる。ARIA in HTML 及び Using ARIA も参照のこと。

特定のランドマークロールがページ上で複数回使用できる場合があり、主要及び補助のナビゲーションメニューのようなものを表すことができる。この場合、同一ロールは、領域にラベル付けを行うための有効な技術を用いて、互いに曖昧さをなくすべきである (下記の例を参照)。

ランドマークは、HTML の見出し、リスト、及びその他の構造的マークアップのようなネイティブセマンティックマークアップの補足となるべきである。ランドマークは、WAI-ARIA 対応の支援技術によって解釈可能であり、ブラウザによって利用者に直接公開されるものではない。

ページ上のすべてのコンテンツをランドマークに含めることがベストプラクティスであり、そうすればセクションからセクションへナビゲートするためにランドマークに依存するスクリーンリーダー利用者がコンテンツの経路を見失うことはなくなる。

事例

訳注: HTML4 及び XHTML 1.0 は Superseded Recommendation としてマークされ、廃止された仕様である。

事例 1: 単純なランドマーク

次の例は、ランドマークがどのように HTML4 や XHTML 1.0 文書に追加され得るのかを示している:

<div id="header" role="banner">A banner image and introductory title</div>
<div id="sitelookup" role="search">....</div>
<div id="nav" role="navigation">...a list of links here ... </div>
<div id="content" role="main"> ... Ottawa is the capital of Canada ...</div>
<div id="rightsideadvert" role="complementary">....an advertisement here...</div>
<div id="footer" role="contentinfo">(c)The Freedom Company, 123 Freedom Way, Helpville, USA</div>

事例 2: 同じ種類の複数のランドマークと aria-labelledby

次の例は、同じページで二つ以上の同じ種類のランドマークが存在する状況で、ランドマークがどのように HTML4 や XHTML1.0 文書に追加されうるのかのベストプラクティスを示している。たとえば、navigation ロールがウェブページ上で複数回使用される場合、各箇所は aria-labelledby を使用して、指定された一意のラベルを持ってもよい:

<div id="leftnav" role="navigaton" aria-labelledby="leftnavheading">
<h2 id="leftnavheading">Institutional Links</h2>
<ul><li>...a list of links here ...</li> </ul></div>
<div id="rightnav" role="navigation" aria-labelledby="rightnavheading">
<h2 id="rightnavheading">Related topics</h2>
<ul><li>...a list of links here ...</li></ul></div>

事例 3: 同じ種類の複数のランドマークと aria-label

次の例は、同じページで二つ以上の同じ種類のランドマークが存在する状況で、ラベルとして参照できるページでテキストが存在しない場合、ランドマークがどのように HTML4 や XHTML 1.0 文書に追加されうるのかのベストプラクティスを示している。

<div id="leftnav" role="navigaton" aria-label="Primary">
<ul><li>...a list of links here ...</li></ul> </div>
<div id="rightnav" role="navigation" aria-label="Secondary">
<ul><li>...a list of links here ...</li> </ul></div>

事例 4: 検索フォーム

次の例は、"search" ランドマークをもつ検索フォームを示す。search ロールは一般に、フォームフィールド又は、検索フォームを囲む div に置かれる。

<form role="search">
<label for="s6">search</label><input id="s6" type="text" size="20">
...
</form>

参考リソース

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

検証

手順

ランドマークロールをもつ各要素を検査する。
ランドマークロール属性が、そのロールに対応するページのセクションに適用されている (すなわち、"navigation"ロールはナビゲーションセクションで適用され、"main" ロールはメインコンテンツが始まる場所に適用される) かどうかを検査する。

期待される結果

1. 及び 2. の結果が真である。

ARIA12: 見出しを特定するために role=heading を使用する

適用 (対象)

Accessible Rich Internet Applications (WAI-ARIA) をサポートするウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

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

ARIA12 に関するユーザエージェントサポートノートを参照のこと。WAI-ARIA 技術ノートも参照。

解説

この達成方法の目的は、支援技術 (AT) に見出しとしてひとまとまりのコンテンツを識別するための手段を提供することである。要素に role="heading" を適用することで、(スクリーンリーダーなどの) 支援技術に、あたかもそれが見出しであったかのように扱わせることができる。

ページ上に複数の見出しがあり、かつ見出し階層が視覚的な提示を通して定義される場合、見出しの階層レベルを示すために aria-level 属性が使用されるべきである。

可能な場合、ネイティブな見出しマークアップを直接使用すること。たとえば、<div role="heading" aria-level="1"> を使用するのではなく、h1 を使用するのが好ましい。しかし、見出しマークアップの代わりに heading ロールを使用することが必要な場合がある。たとえば、スクリプトが既存の要素の階層構造に依存しているレガシーサイトを改装する場合などである。

heading ロールとネスティングレベルの用途については、WAI-ARIA 1.0 Authoring Practices で説明されている。

訳注: heading ロールとネスティングレベルの用途に関する「WAI-ARIA 1.0 Authoring Practices」のリンクは、正しくは WAI-ARIA 1.0 Authoring Practices§3.2.7.3. Implicit Nesting and Headings となる。しかしながら、この文書は古い文書であり、最新の　Authoring Practices である WAI-ARIA Authoring Practices 1.1 において、対応する記述は見当たらないことに注意する。

事例

事例 1: 単純な見出し

この例は、スクリプトが既存の要素の階層構造に依存する、又はレベルが不明であるレガシーなサイトを改装する際に、role="heading" を使用した簡単な見出しを実装する方法を示す。たとえば、さまざまなソースからシンジケートされたウェブコンテンツを、最終的なプレゼンテーションがどうなるかの知識なしで構築できるかもしれない。

<div role="heading">Global News items</div>
... a list of global news with editorial comment....

<div role="heading">Local News items</div>
... a list of local news, with editorial comment ...

事例 2: 追加の見出しレベル

この例は、role="heading" と aria-level 属性を用いてレベル7見出しを実装する方法を示す。HTMLはレベル6までの見出しのみをサポートしているため、このセマンティックスを提供するためのネイティブ要素は存在しない。

...
<h5>Fruit Trees</h5>
...
<h6>Apples</h6>
<p>Apples grow on trees in areas known as orchards...</p>
...
<div role="heading" aria-level="7">Jonagold/div>
<p>Jonagold is a cross between the Golden Delicious and Jonathan varieties...</p>

参考リソース

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

検証

手順

属性 role="heading" をもつ各要素を調べる。
要素の内容が見出しとして適切であるかどうかを判断する。
要素が aria-level 属性を持つ場合、値が適切な階層レベルであるかどうかを判断する。

期待される結果

2. 及び 3. の結果が真である。

ARIA13: リージョンとランドマークに名前 (name) を付けるために、aria-labelledby を使用する

適用 (対象)

Accessible Rich Internet Applications (WAI-ARIA) をサポートするウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

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

ARIA13 に関するユーザエージェントサポートノートを参照のこと。WAI-ARIA 技術ノートも参照。

解説

この達成方法の目的は、支援技術によって読み取ることができるページの領域に対して名前を提供することである。aria-labelledby 属性は、領域又はランドマークとしてマークアップされたページ内のセクションと、そのセクションを分類するページ内のテキストを関連付ける方法を提供する。

ランドマークロール (又はランドマーク) は、ページのセクションをプログラムで識別できるようにする。

ランドマークは、支援技術 (AT) 利用者がページに順応するのを支援し、様々なページのセクションにより簡単にナビゲートするのに役立つ。aria-describedby のように、aria-labelledby は、スペース区切りのリストを使用して、ページの他の領域を指すための複数の ID を受け入れることができる。また、この集合を定義するものは ID に限定されている。

事例

事例 1: ページ上のテキストをもつランドマークを識別する

以下は、complementary ランドマークに aria-labelledby を使用した一例である。この文書内の見出しがついている領域は、見出しの id 値を含む aria-labelledby プロパティによってマークすることができる。

<p role="complementary" aria-labelledby="hdr1">
 <h1 id="hdr1">
    Top News Stories
 </h1>
</p>

事例 2: アプリケーションランドマークの識別

次のコード断片は、静的な文を含む application ランドマークである。タイプ application の領域ランドマークがあり、かつ静的な説明テキストが利用可能であるため、application ランドマークには、そのアプリケーションと静的テキストを関連付けるための aria-describedby による参照を含めている。

<div role="application" aria-labelledby="p123" aria-describedby="info">
<h1 id="p123">Calendar<h1>
<p id="info">
This calendar shows the game schedule for the Boston Red Sox.
</p>
<div role="grid">
....
</div>

参考リソース

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

検証

手順

属性 role=region 又はランドマークロールを持ち、aria-labelledby 属性も存在している各要素を調べる。
aria-labelledby 属性値が、ページ上の要素の id であることを確認する。
その id を持つ要素のテキストが、ページのセクションを正確にラベル付けしていることを確認する。

期待される結果

2. 及び 3. の結果が真である。

ARIA14: 可視ラベルが使用できない場所で不可視ラベルを提供するために、aria-label を使用する

適用 (対象)

Accessible Rich Internet Applications (WAI-ARIA)をサポートするウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- クイックリファレンス 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- 達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )を理解する

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

ARIA14 に関するユーザエージェントサポートノートを参照のこと。WAI-ARIA 技術ノートも参照。

解説

目の見える利用者の場合、要素のコンテキスト及び外観は目的を決定するために十分な手がかりを提供できる。一例は、ポップアップの div (ライトボックス) を閉じるためのコントロールを示すために、この div の右上隅でよく使用される 'X' である。

設計手法やレイアウトによって、可視のラベルが存在しないが、コンテキストと視覚的な外観によってコントロールの目的が明確になっているような場合、要素には、アクセシブルな名前を提供するために、aria-label 属性を与えられることがある。

この他、ネイティブ HTML ラベル要素がコントロールでサポートされない場合、要素には、アクセシブルな名前を提供するために属性 aria-label が与えられることがある――たとえば、よりリッチなテキスト編集体験を提供するために、div が contentEditable に設定され、input type="text" や textarea などのネイティブフォーム要素の代わりに使用される場合である。

事例

事例 1: ポップアップボックスにおける閉じるボタン (X)

ページ上で、リンクは追加情報をもつポップアップボックス (div) を表示する。その close (閉じる) 要素は、単に文字 'x' を含むボタンとして実装される。プロパティ aria-label="close" は、ボタンにアクセシブルな名前を提供するために使用される。

<div id="box">
   This is a pop-up box.
   <button aria-label="Close" onclick="document.getElementById('box').style.display='none';" class="close-button">X</button>				
</div>

実装例: 閉じるボタンの例。

事例 2: 複数のフィールドを持つ電話番号

<div role="group" aria-labelledby="groupLabel">
  <span id="groupLabel>Work Phone</span>
  +<input type="number" aria-label="country code">
  <input type="number" aria-label="area code">
  <input type="number" aria-label="subscriber number">
</div>

参考リソース

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

検証

手順

aria-label を使用する要素に対して:

利用者の入力が要求される場所で aria-label 属性の値が適切に要素の目的を説明していることを確認する

期待される結果

1. の結果が真である。

ARIA15: 画像の説明を提供するために aria-describedby を使用する

適用 (対象)

Accessible Rich Internet Applications (WAI-ARIA)をサポートするウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

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

ARIA15 に関するユーザエージェントサポートノートを参照のこと。WAI-ARIA 技術ノートも参照。

解説

この達成方法の目的は、簡潔なテキストによる代替がオブジェクトで提供される機能や情報を適切に伝達しない場合に、画像の説明を提供することである。

WAI-ARIA には、aria-describedby プロパティを使用して、セクション、描画、フォーム要素、画像などと説明テキストを関連付けできる機能がある。これは、利用者が複雑な画像を理解するのを助ける追加情報を提供するのに両者が有用であるという点において longdesc 属性に似ている。longdesc のように、aria-describedby を使用して提供される説明テキストは、HTML で alt 属性を使用して提供される短い名前とは別のものである。longdesc と異なり、aria-describedby は画像を含むページの外の記述を参照できない。画像と同じページのコンテンツを使用して長い説明を提供する利点は、支援技術を持たない、目の見える人を含め、その代替が誰でも利用できることである。執筆時点 (2013 年 10 月) で、一部の支援技術が利用者の操作なしに画像の alt 属性情報の直後に aria-describedby の内容を読みあげることは注目に値する――これは、longdesc 属性のほとんどの実装が、追加の説明を読むために利用者の明示的な操作を必要とすることとは対照的である。

aria-labelledby のように、aria-describedby は、スペース区切りのリストを使用してページの他の領域を指すための複数の ID を受け入れることができる。この集合を定義するものは ID に限定されている。

事例

事例 1: 画像を説明する

次の例は、テキストの説明が画像と同じページ上にある場所で、長い説明を提供するためにどのように aria-describedby が画像に適用されるかを示す。

<img src="ladymacbeth.jpg" alt="Lady MacBeth" aria-describedby="p1">
<p id="p1">This painting dates back to 1730 and is oil on canvas. It was created by 
Jean-Guy Millome, and represents ...</p>

参考リソース

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

検証

手順

aria-describedby 属性が存在する各画像要素を調べる。
その aria-describedby 属性が、その説明として用いられるテキストを含む要素の id を介して、要素とテキストの説明とをプログラム的に関連付けているかどうかを調べる。
結合された同等のテキスト及び関連付けられたテキストの説明が、オブジェクトに同等の目的を正確に説明する又は提供していることを調べる。

期待される結果

1.、2. 及び 3. の結果が真である。

ARIA16: ユーザインターフェースコントロールの名前 (name) を提供するために、aria-labelledby を使用する

適用 (対象)

Accessible Rich Internet Applications (WAI-ARIA)をサポートするウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

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

ARIA16 に関するユーザエージェントサポートノートを参照のこと。WAI-ARIA 技術ノートも参照。

解説

この達成方法の目的は、支援技術によって読み取ることができるユーザインタフェースコントロールの名前を提供することである。WAI-ARIA は、aria-labelledby プロパティを使用して、セクション、描画、フォーム要素、画像などとテキストを関連付けるための方法を提供する。この達成方法では、aria-labelledby 属性を使用して、フォームフィールドなどのユーザインタフェースコントロールと、それをラベル付けするページ上のテキストとを関連付ける。

aria-describedby のように、aria-labelledby は、スペース区切りのリストを使用して、ページの他の要素を指すように複数の ID を受け入れることができる。この機能は、目の見える利用者がコントロールを識別するために周囲のコンテキストからの情報を使用する状況において、aria-labelledby を特に有用にする。複数の語句をつなげて一つのラベルにするために、aria-labelledby を使用するでも、名前がページ上の他の複数のテキスト要素から構成される場合の事例を紹介している。

aria-labelledby の機能はネイティブな HTML の label 要素と似ているように見えるが、いくつか違いがある:

aria-labelledby は複数のテキスト要素を参照することができる。label が参照できるのは一つだけである。
label 要素がフォーム要素のみに使用できる一方で、aria-labelledby はさまざまな要素に対して使用できる。
label をクリックすると、関連付けられたフォームフィールドをフォーカスする。これは aria-labelledby では起こらない。この動作が必要な場合、label を使用するか、スクリプトを使用してこの機能を実装する。

2013 年 12 月の時点で、特に古いブラウザや支援技術で、label のほうが aria-labelledby よりもより良くサポートされていることに注意すること。

事例

事例 1: 単純なテキストフィールドをラベル付けする

以下は、ラベル専用のテキストがないものの、正確にコントロールをラベル付けするためにページ上の他のテキストが使用できる状況で、aria-labelledby を使用して単純なテキストフィールドにラベルを提供している例である。

<input name="searchtxt" type="text" aria-labelledby="searchbtn">
<input name="searchbtn" id="searchbtn" type="submit" value="Search">

事例 2: スライダーをラベル付けする

以下は、スライダーコントロールにラベルを提供するために aria-labelledby を使用している例である。このケースでは、ラベルテキストが、より長い隣接するテキスト文字列の中から選択される。この例は、単にラベル付けの関係を示すために簡略化されていることに注意すること。カスタムコントロールを実装するコンテンツ制作者は、コントロールが他の達成基準を満たしていることも確認する必要がある。

<p>Please select the <span id="mysldr-lbl">number of days for your trip</span></p>
<div id="mysldr" role="slider" aria-labelledby="mysldr-lbl"></div>

事例 3: 複数のソースからのラベル

以下は、label 要素を使用した複数の参照を伴う aria-labelledby の例である。aria-labelledby をもつラベルに複数のソースを連結する方法の詳細については、複数の語句をつなげて一つのラベルにするために、aria-labelledby を使用するを参照すること。

<label id="l1" for="f3">Notify me</label>
<select name="amt" id="f3" aria-labelledby="l1 f3 l2">
  <option value="1">1</option>
  <option value="2">2</option>
</select>
<span id="l2" tabindex="-1">days in advance</span>

注: label 要素を使うことには多くの理由がある。利用者が label 要素のテキストをクリックすれば、対応するフォームフィールドがフォーカスを受け取るため、器用さの問題を持つ人に対してクリックターゲットを大きくすることができる。また、label 要素は常にアクセシビリティ API を介して公開される。span が使われるかもしれない (ただしその場合、span が Internet Explorer のすべてのバージョンでアクセシビリティ API を介して公開されるように、span は tabindex="-1" を与えるべきである)。しかし、span では、クリック可能な領域が大きくなるという利点が失われることになるだろう。

参考リソース

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

検証

手順

aria-labelledby 属性が存在する場合に各ユーザインタフェースコントロール要素に対して:

aria-labelledby 属性の値は、ある要素の id、又はウェブページ上の複数 id のスペース区切りのリストであることを確認する。
参照される要素又は複数要素のテキストが正確にユーザインタフェースコントロールにラベル付けすることを確認する。

期待される結果

1. 及び 2. の結果が真である。

ARIA17: 関連するフォームコントロールを特定するために、グルーピングロールを使用する

適用 (対象)

Accessible Rich Internet Applications (WAI-ARIA)をサポートするウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

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

ARIA17 に関するユーザエージェントサポートノートを参照のこと。WAI-ARIA 技術ノートも参照。

解説

この達成方法の目的は、グループのように、フォーム内部で関連するコントロールのセットをマークアップすることである。グループに関連付けられた任意のラベルは、グループ内の個別のコントロールに対する共通のラベル又は修飾子としても機能する。支援技術は、グループ内および外へのナビゲーションの際に、グループの開始と終了、およびグループのラベルを示すことができる。これは、ユーザインタフェースのデザインが fieldset と legend による達成方法 (H71) を採用することが困難である場合に、プログラム的にフォームコントロールをグループ化するために実行可能な代替手段である。

ラジオボタングループの場合、role="group" の代わりに role="radiogroup" を使用できる。

グループは aria-labelledby を使用してラベル付けできる。

この達成方法は、role="group" をもつ単一のコンテナ内にフォーム上のすべてのコントロールを包むためのものではない。

事例

事例 1: 社会保障番号

9 桁の長さで、三つのセグメントに分割される社会保障番号フィールドは、role="group" を使用してグループ化できる。

<div role="group" aria-labelledby="ssn1">
   <span id="ssn1">Social Security#</span> 
   <span style="color: #D90D0D;"> * </span>
   <input size="3" type="text" aria-required="true" title="First 3 digits" />-
   <input size="2" type="text" aria-required="true" title="Next 2 digits" />-
   <input size="4" type="text" aria-required="true" title="Last 4 digits" />
</div>

実装例: 複数パートに分かれたフィールドのグループ化。

事例 2: ラジオグループを識別する

この例は、role=radiogroup のデモである。ラジオボタンが role=radio をもつカスタムコントロールであることにも注意。(しかし span を実際にラジオボタンのように動作させるためのスクリプトは、この例には含まれていない。) 必要に応じて、グループの関係を視覚的に強調するために、フィールドのようにグループの周りにボーダーを配置するために CSS を使用してもよい。CSS プロパティはフォームの下にある。

<h3>Set Alerts for your Account</h3>
  <div role="radiogroup" aria-labelledby="alert1">
    <p id="alert1">Send an alert when balance exceeds $ 3,000</p>
    <div>
      <span role="radio" aria-labelledby="a1r1" name="a1radio"></span>
      <span id="a1r1">Yes</span>
    </div>
    <div>
      <span role="radio" aria-labelledby="a1r2" name="a1radio"></span>
      <span id="a1r2">No</span>
    </div>
  </div>
  <div role="radiogroup" aria-labelledby="alert2">
    <p id="alert2">Send an alert when a charge exceeds $ 250</p>
    <div>
      <span role="radio" aria-labelledby="a2r1" name="a2radio"></span>
      <span id="a2r1">Yes</span>
    </div>
    <div>
      <span role="radio" aria-labelledby="a2r2" name="a2radio"></span>
      <span id="a2r2">No</span>
    </div>
  </div>
  <p><input type="submit" value="Continue" id="continue_btn" name="continue_btn" /></p>

フィールドのグループの周りにボーダーを配置するための、関連する CSS スタイル定義:

div[role=radiogroup] {
  border: black thin solid;
}

参考リソース

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

Accessible Rich Internet Applications (WAI-ARIA) 1.0, The Roles Model

H71: fieldset 要素及び legend 要素を使用して、フォームコントロールのグループに関する説明を提供する

検証

手順

各コントロールに対する個別のラベルが十分な説明を提供せず、かつ追加のグループレベルの説明が必要とされる場合、関連するコントロールグループに対して:

論理的に関連する input 又は select 要素のグループが role=group をもつ要素内に含まれていることを確認する。
このグループが aria-label 又は aria-labelledby を使用して定義されるアクセシブルな名前を持つことを確認する。

期待される結果

1. 及び 2. の結果が真である。

ARIA18: エラーを特定するために aria-alertdialog を使用する

適用 (対象)

Accessible Rich Internet Applications (WAI-ARIA) をサポートするウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

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

ARIA18 に関するユーザエージェントサポートノートを参照のこと。WAI-ARIA 技術ノートも参照。

解説

この達成方法の目的は、入力エラーが発生していることを利用者に警告することにある。role="alertdialog"を使用することで、通知を作成することができる。この通知は、次のような特徴をもつモーダルであるべきである:

aria-label 又は aria-labelledby 属性で、アラートダイアログにアクセシブルな名前を与えている。
aria-describedby で、アラートのテキストへの参照を提供している。
そのアラートダイアログは、少なくとも一つのフォーカス可能なコントロールを含んでおり、アラートダイアログが開く際にフォーカスがそのコントロールに移動すべきである。
タブ順序は、タブが開いている間アラートダイアログの内部に拘束される。
ダイアログが閉じられる場合、可能であれば、フォーカスはダイアログが開く前の位置に戻る。

アラートダイアログは、必要とされるまで、支援技術によってアクセスされる方法で存在すべきではないことに注意。これを行う一つの方法は、静的な HTML に含めない代わりに、エラー状態がトリガーされた時にスクリプトを通して DOM に挿入することである。この挿入は、次の HTML サンプルに対応する。

事例

事例 1: アラートダイアログ

この例は、role="alertdialog"を使用する通知が、無効な情報を入力した人に通知するためにどのように使用できるかを示す。

<div role="alertdialog" aria-labelledby="alertHeading" aria-describedby="alertText">
<h1 id="alertHeading">Error</h1>
<div id="alertText">Employee's Birth Date is after their hire date. Please verify the birth date and hire date.</div>
<button>Save and Continue</button>
<button>Return to page and correct error</button>
</div>

実装例: アラートダイアログ。

参考リソース

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

WAI-ARIA Authoring Practices 1.1

(今のところ、なし。)

検証

手順

アラートダイアログが表示される原因となるエラーをトリガーする。
アラートダイアログは少なくとも一つのフォーカス可能なコントロールを含み、アラートダイアログが開いた際にフォーカスがそのコントロールに移動することを判断する。
タブ順序は、タブが開いている間アラートダイアログ内に拘束され、ダイアログを閉じた際に、可能ならば、フォーカスはダイアログが開く前の位置に戻ることを判断する。
適用された role="alertdialog" をもつ要素を調べる。
aria-label 又は aria-labelledby 属性のいずれかが、適切にアラートダイアログにアクセシブルな名前を与えるために使用されていることを判断する。
アラートダイアログのコンテンツが入力エラーを識別していることを判断する。
アラートダイアログのコンテンツがエラーを修正する方法を提案しているかどうかを判断する。

期待される結果

2.、3.、5. 及び 6. の結果が真である。達成基準 3.3.3 を達成するためには、7 の結果も真である。

ARIA19: エラーを特定するために、ARIA role=alert 又はライブリージョン (Live Regions) を使用する

適用 (対象)

Accessible Rich Internet Applications (WAI-ARIA) をサポートするウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

達成基準 3.3.1 (エラーの特定)
- クイックリファレンス 3.3.1 (エラーの特定)
- 達成基準 3.3.1 (エラーの特定)を理解する

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

ARIA19 に関するユーザエージェントサポートノートを参照のこと。WAI-ARIA 技術ノートも参照。

解説

この達成方法の目的は、入力エラーが発生した場合に支援技術 (AT) に通知することである。aria-live 属性は、エラーメッセージがライブ領域のコンテナに注入された際に、AT (スクリーンリーダーなど) による通知を可能にする。aria-live 領域内部のコンテンツは、テキストが表示されている場所で AT がフォーカスする必要なしに、AT によって自動的に読みあげられる。

ライブ領域のプロパティを直接適用する代わりに使用できる特殊ケースのライブ領域のロールも多数ある。

訳注: 「特殊ケースのライブ領域のロール」のリンクは、正しくは WAI-ARIA 1.0 Authoring Practices§5.3. Choosing Between Special Case Live Regions となる。しかしながら、この文書は古い文書である。ライブ領域のロールについては、WAI-ARIA 1.1§5.3.5 Live Region Roles も参照されたい。

事例

事例 1: DOM 内にすでに存在する role=alert をもつコンテナの中にエラーメッセージを注入する

次の例は、aria-live=assertive を使用しているのと同等の role=alert を使用する。

例において、ページロード時に DOM に存在する aria-atomic=true 及び aria-live プロパティ又は alert ロールをもつ空のエラーメッセージコンテナ要素が存在する。エラーコンテナは、ほとんどのスクリーンリーダーでエラーメッセージが読み上げられるために、ページロード時に DOM に存在しなければならない。aria-atomic=true は、複数の無効な投稿をした後にエラーメッセージを iOS の Voiceover に読み上げさせるために必要である。

jQuery は、送信時に入力が空であるかどうかをテストし、そうであれば、ライブ領域コンテナにエラーメッセージを注入するために使用される。新しい送信が試みられるたびに、前のエラーメッセージがコンテナから削除され、新しいエラーメッセージが挿入される。

<script src="http://code.jquery.com/jquery.js"></script>
<script>
$(document).ready(function(e) {
	$('#signup').submit(function() {
		$('#errors').html('');
		if ($('#first').val() === '') {
			$('#errors').append('<p>Please enter your first name.</p>');
		}
		if ($('#last').val() === '') {
			$('#errors').append('<p>Please enter your last name.</p>');
		} 
		if ($('#email').val() === '') {
			$('#errors').append('<p>Please enter your email address.</p>');
		} 
		return false;
	});
});
</script>

<form name="signup" id="signup" method="post" action="">
  <p id="errors" role="alert" aria-atomic="true"></p>
  <p>
    <label for="first">First Name (required)</label><br>
    <input type="text" name="first" id="first">
  </p>
  <p>
    <label for="last">Last Name (required)</label><br>
    <input type="text" name="last" id="last">
  </p>
  <p>
    <label for="email">Email (required)</label><br>
    <input type="text" name="email" id="email">
  </p>
  <p>
    <input type="submit" name="button" id="button" value="Submit">
  </p>
</form>

実装例: エラーを識別するために role=alert を使用する。

参考リソース

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

(今のところ、なし。)

検証

手順

role=alert 又は aria-live=assertive 属性が指定された空のエラーコンテナが、ページの読み込み時の DOM に存在することを判断する。
ライブ領域のコンテンツの表示又更新を引き起こすエラーをトリガーする。
エラーメッセージが既に存在するエラーコンテナに挿入されたことを判断する。

期待される結果

1. 及び 3. の結果が真である。

ARIA20: ページのリージョンを特定するために region ロールを使用する

適用 (対象)

Accessible Rich Internet Applications (WAI-ARIA)をサポートするウェブコンテンツ技術。

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

解説

この達成方法は、ユーザエージェント及び支援技術がプログラム的にページのセクションを識別できるように、そのページのセクションに一般的な region ロールを割り当てる方法を示す。region ロールは、より容易に発見可能かつナビゲート可能であるように、重要なコンテンツを含むページの区切りを定める。一般的な領域は、セクションが標準の文書ランドマークロールによってマークアップできない場合に使用されるべきである (ARIA11: ページのリージョンを特定するために ARIA ランドマークを使用する (ARIA) を参照)。

領域は一般的なグループ化された要素であり、かつ利用者がどの領域にいるのかを伝えるための手段が必要になるため、領域に名前を付けることは重要である。領域には、aria-labelledby や aria-label、その他の手法を使用して名前を付けることができる。そうすることで、ページ上のコンテンツと情報の関係をより良く公開する助けとなる。過剰に使用した場合、スクリーンリーダーの利用者に対してページを過度に冗長にすることがあるので、region のロールは、慎重に使用するべきである。

事例

事例 1: ニュースサイト上の領域

毎週変更する世論調査を含むニュースサイトのホームページ上のセクションが、role="region" でマークアップされている。フォーム上部の h3 テキストは、aria-labelledby を使うことで領域の名前として参照されている。


<div role="region" aria-labelledby="pollhead">
<h3 id="pollhead">This week's Poll</h3>
<form method="post" action="#">
  <fieldset>
    <legend>Do you believe the tax code needs to be overhauled?</legend>
    <input type="radio" id="r1" name="poll" />
    <label for="r1">No, it's fine the way it is</label>
    <input type="radio" id="r2" name="poll" />
    <label for="r2">Yes, the wealthy need to pay more</label>
    <input type="radio" id="r3" name="poll" />
    <label for="r3">Yes, we need to close corporate loopholes</label>
    <input type="radio" id="r4" name="poll" />
    <label for="r4">Changes should be made across the board</label>
  </fieldset>
</form>
<a href="results.php">See Poll Results</a>
</div>

事例 2: 銀行サイト上の領域を識別する

利用者は、銀行のウェブサイトにログインした後、リンクを展開することで定期預金口座の詳細を確認できるようになっている。詳細は、region ロールでマークアップされた範囲の中にある。その領域の見出しは role=heading を持ち、その領域に名前を付ける aria-labelledby の中に含まれている。


<ol>
	<li><a id="l1" href="#" aria-expanded="false" title="Show details" aria-controls="block1" >John Henry's Account</a><img src="images/panel_expand.gif" alt="" />
		 <div id="block1" class="nowHidden" tabindex="-1" aria-labelledby="l1 cd1" role="region"><span id="cd1" role="heading" aria-level="3">Certificate of  Deposit:</span>
		 <table>
			 <tr><th scope="row">Account:</th> <td>25163522</td></tr>
			 <tr><th scope="row">Start date:</th> <td>February 1, 2014</td></tr>
			 <tr><th scope="row">Maturity date:</th><td>February 1, 2016</td></tr>
			 <tr><th scope="row">Deposit Amount:</th> <td>$ 3,000.00</td></tr>
			 <tr><th scope="row">Maturity Amount:</th> <td>$ 3,072.43</td></tr>
		 </table>
		 </div>
	 </li>
 </ol>

事例 3: 一般的な領域とポートレットを同一視する

コード例:


<div role="region" aria-label="weather portlet"> 
	...
</div>

参考リソース

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

The Roles Model (role=region)

検証

手順

role="region"でマークアップされる各セクションに対して:

コンテンツを調べ、独立したランドマークを持つのに十分なほど重要であることを確認する。
標準のランドマークロールがこのコンテンツに適さないことを確認する。
領域がプログラムによる解釈が可能な名前を持つことを確認する。

期待される結果

1. から 3. の結果が真である。

ARIA21: エラーフィールドを示すために aria-invalid を使用する

適用 (対象)

Accessible Rich Internet Applications (WAI-ARIA) を用いる HTML。

これは、次の達成基準に関連する達成方法である:

達成基準 3.3.1 (エラーの特定)
- クイックリファレンス 3.3.1 (エラーの特定)
- 達成基準 3.3.1 (エラーの特定)を理解する

解説

この達成方法は、aria-invalid を使用して、検証に失敗しているフィールドを明確に識別する方法を示す。次の場合が最も使用に適している:

エラーの説明から、失敗したフィールドをプログラムによって識別できない。
失敗したフィールドが、一部の利用者に利用できない方法で――たとえば、色に依存しない、ボーダーのような視覚的な手がかりなどの技術によって視覚的にレンダリングされるエラーアイコンの使用によって――識別される。

注記: 上記二つの状況の一つは、データフォーマット、データ範囲、又はrequired プロパティを伝えるラベル及び／又は命令とプログラムによって関連付けられているフィールドにも起こりうる。

失敗したフィールドと具体的なエラーの説明をプログラム的に関連付けることが常に望ましい一方で、ページのデザイン又は利用されているフレームワークは、コンテンツ制作者がプログラム的に関連付けるための能力を制約するかもしれない。このような場合、コンテンツ制作者は、検証に失敗したフィールド上でプログラムによって aria-invalid を "true" に設定してもよい。これは主に、目の不自由な利用者によって使用される (スクリーンリーダー/画面拡大のような) 支援技術で解釈可能である。フィールドが "true" に設定された aria-invalid を持つ場合、フィールドがフォーカスを取得する際に、Safari の VoiceOver は "invalid data" とアナウンスし、JAWS と NVDA は "invalid entry" としてエラーを通知する。

この ARIA 属性は、プログラムによって設定/オンにされる必要がある。入力の検証が行われる又はフォームが送信される前に、その属性を "true" に設定するべきではない。aria-invalid を "false" に設定することは、フォームコントロールにこの属性を全く指定しないことと同じである。当然ながら、この場合、支援技術は利用者に何も伝えない。

可視テキストが、失敗したフィールドをプログラムによって識別する及び／又はエラーを補正できる方法を伝えるために使用される場合、aria-invalid を "true" に設定することは、厳格な整合性の観点からは必要とされないが、それでも利用者のために役立つ情報を提供する可能性がある。

事例

事例 1: 必須フィールドに aria-invalid を使用する

何も入力されていない必須フィールドに aria-invalid 属性が指定されている。フォーム上部のメッセージは、フォームの送信がこのせいで失敗したことを伝えている。

jQuery コード及び HTML フォームマークアップの一部は次のとおりである:


<script>
...
...
		if ($('#first').val() === '') {
			$('#first').attr("aria-invalid", "true");
$("label[for='first']").addClass('failed');
		}
		if ($('#last').val() === '') {
			$('#last').attr("aria-invalid", "true");
$("label[for='last']").addClass('failed');
		} 
		if ($('#email').val() === '') {
			$('#email').attr("aria-invalid", "true");
$("label[for='email']").addClass('failed');
		} 
...
...
</script>
<style type="text/css">
label.failed {
	border: red thin solid;
}
</style>
<form name="signup" id="signup" method="post" action="#">
 <p>
    <label for="first">First Name (required)</label><br>
    <input type="text" name="first" id="first">
  </p>
  <p>
    <label for="last">Last Name (required)</label><br>
    <input type="text" name="last" id="last">
  </p>
  <p>
    <label for="email">Email (required)</label><br>
    <input type="text" name="email" id="email">
  </p>
  <p>
    <input type="submit" name="button" id="button" value="Submit">
  </p>
</form>

動作する例。

事例 2: データフォーマットのエラーを識別する

Aria-invalid 及び aria-describedby が、個人識別番号 (PIN)、電子メールアドレス、又は開始日が期待される形式でない場合に、エラーを示すために一緒に使用されている。エラーメッセージは、aria-describedby を使うことでフィールドに関連付けられており、aria-invalid によって、エラーになっているフィールドをプログラムによって簡単に見つけられるようになっている。

以下は、事例 1 において電子メールアドレスフィールドにレンダリングされる HTML コードである。(sam@example.com の代わりに) "samexample.com" のような不正な電子メールアドレスが利用者によって入力された場合、HTML コードは次のようになる:


<div class="control">
<p><label for="email">Email address: [*]</label> 
<input type="text" name="email" id="email" class="error" aria-invalid="true" aria-describedBy="err_1" /></p> 
<span class="errtext" id="err_1">Error: Incorrect data</span></div>

そしてデータが電子メールフィールドに入力されなかった場合、HTML コードは次のようになる:


<div class="control">
<p><label for="email">Email address: [*]</label> 
<input type="text" name="email" id="email" class="error" aria-invalid="true" aria-describedBy="err_2" /></p>
<span class="errtext" id="err_2">
 Error: Input data missing</span>
</div>

jQuery コード: jQuery は、class 属性だけでなく aria-invalid 又は aria-describedby 属性をも追加し、かつエラーテキストを追加するために使用される。これは、aria-invalid 及び class="error" を挿入するコードであるが、プログラム的にコントロールとエラーテキスト "incorrect data" を関連付けないコードである:


$(errFld).attr("aria-invalid", "true").attr("class", "error");
// Suffix error text: 
$(errFld).parent().append('<span class="errtext">Error: Incorrect data</span>');

CSS コード:


input.error {
   border: red thin solid;}
span.errtext {
	margin-bottom: 1em; 	padding: .25em 1.4em .25em .25em;
	border: red thin solid; 	background-color: #EEEEFF;
	background-image:url('images/iconError.gif');
	background-repeat:no-repeat; 	background-position:right;	
}

動作する例.

参考リソース

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

検証

手順

検証の失敗の伝達を aria-invalid に依存する各フォームコントロールに対して:

検証の失敗が存在しない場合に aria-invalid が true に設定されないことを確認する。
検証の失敗が存在する場合に aria-invalid が true に設定されることを確認する。
プログラム的に関連付けられたラベル/プログラム的にフィールドに関連づけられた説明文がエラーを理解するのに十分な情報を提供していることを確認する。

期待される結果

1. から 3. の結果が真である。

9. Flashの達成方法

Flash テクノロジーノート

訳注: Flash Player は、2020 年末に提供を終了する計画が Adobe 社より発表されている (Adobe Blog、窓の杜)。

WAIC での Flash に関する翻訳のメンテナンスも積極的に行う予定がないことに留意されたい。

Adobe Flash Player は、クロスプラットフォームなブラウザのプラグインである。Flash Player によって表示されるコンテンツの制作者は、映像サポート、オーサリングの好み、ベクターベースのグラフィック能力などの様々な要因から Flash Player を用いてコンテンツを提供したり、Flash の標準コンポーネントを利活用したりすることを選択する。コンテンツ制作者が Flash を用いるそういった動機が何であれ、他のウェブコンテンツ技術を用いたウェブコンテンツと同様に、Flash Player で提供されるコンテンツが WCAG 2.0 のアクセシビリティ基準を満たすようにすることは重要である。

Flash のユーザエージェントによるサポート

Flash Player は、アクセシビリティのビルトインでのサポートと、コンテンツ制作者およびオーサリングツールがコンテンツをアクセシブルにするために利活用できる性能とのコンビネーションを提供している。Flash コンテンツ制作者は、アクセシブルな Flash コンテンツを制作するためには次のどのツールを用いてもよい (ただし、必ずしもこれらに限定されない)。

Flash MX, MX2004, 8, CS3, CS4, CS5
Flex 1.5 以降
Flex Builder 2, Flex Builder 3, Flash Builder 4
Flash Catalyst 4
その他、Adobe Presenter、Adobe Captivate など

全盲の利用者、ロービジョンの利用者およびその他の支援技術利用者向けに、Flash Player は 2001 年に Flash Player 6 でアクセシビリティ API のサポートを実現した。Flash のアクセシビリティに関する支援技術サポートは、Flash コンテンツに関する情報を支援技術に正しく伝えるという点においては、MSAA (Microsoft Active Accessibility) インタフェースと Flash Player 特有のインタフェースに依存している。支援技術のサポートは、次の組み合わせによる閲覧環境の利用者に対して提供されている:

Windows OS 上での Internet Explorer 6 以降と Flash Player 6 以降の組み合わせ
Windows OS 上での Mozilla Firefox 3 以降と Flash Player 9 以降の組み合わせ

支援技術による MSAA のサポートは、次のような支援技術製品で提供されている (ただし、必ずしもこれらに限定されない)。

JAWS (4.5 以降)
Window-Eyes (4.2 以降)
NVDA
ZoomText (8 以降)

Flash によるアクセシビリティのサポート

Flash Player は、マウスを使用することのできない利用者向けにキーボード操作もサポートしている。キーボード操作のサポートに関しては、Internet Explorer で用いられている Flash Player の ActiveX 版が最も高いレベルだが、Mozilla Firefox でのサポートを提供するための実装方法もこの文書で提供されている。「WCAG 2.0 実装方法集」で紹介されているように、Flash コンテンツ制作者はパブリッシュしたコンテンツ内でのタブ順序を制御することができる。

Flash player は、映像を表示するのに用いられることが多く、あらゆる言語のクローズドキャプションやサブタイトルを提供することのできるテキストトラックがある。また、音声ガイドを提供できるように複数の音声トラックも用意されている。さらに、視聴覚コンテンツに手話通訳の提供を可能にする映像トラックも複数ある。

現時点では、Flash Player は Windows OS によるハイコントラストモードやテキストのサイズ変更をサポートしていない。しかし、Flash コンテンツ制作者は、Flash によるカスケーディングスタイルシート (CSS) のサポート、その他の標準搭載スタイルのサポート、あるいは Flash の画面フィルタ機能を利用することによって、Flash ベースのインタフェースを大きめのテキストで閲覧可能な代替ビュー、代替フォント、あるいは代替ハイコントラストカラースキームなどを提供することが可能である。

支援技術向けの Flash によるアクセシビリティのサポートは、Windows OS 上で、Internet Explorer 6 以降 (Flash Player 6 以降) または Mozilla Firefox 3 以降 (Flash Player 9 以降) を使用した場合に限られている。

Flash Player に関する詳細な情報は、Adobe サイトで提供されている Flash Player FAQ を参照のこと。

WCAG 2.0 適合に向けた特記事項

2.4.2 ページタイトル - 達成基準 2.4.2 を満たすためには、Flash コンテンツは title 要素によるページタイトルを有した HTML のウェブページ内に埋め込まれていなければならない。H25: title 要素を用いて、ページタイトルを提供する (HTML) を参照のこと。
3.1.1 ページの言語 - Flash コンテンツの言語は、Flash の SWF ファイル自体ではなく、HTML にある object 要素を含んだ部分の lang 属性によって示される。また、コンテンツ制作者は、object 要素の lang 属性によって異なる言語をそれぞれに示した複数の Flash の SWF ファイルを一つのウェブページ内に埋め込むことができる。FLASH13: Flash コンテンツの言語を指定するために、HTML の言語属性を使用するを参照のこと。
3.1.2 部分的に用いられている言語 - Flash コンテンツの言語は、Flash の SWF ファイル内では示すことができないため、現時点では SWF ファイル内での言語の変更を示すことはできない。

FLASH1: 非テキストオブジェクトに name プロパティを設定する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

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

FLASH1 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、支援技術による読み上げが可能になるように Flash 内の非テキストオブジェクトをマークする方法を示すことである。

Flash Player は、非テキストオブジェクトについて、アクセシビリティオブジェクト内の name プロパティを使用したテキストによる代替をサポートしている。このテキストによる代替は ActionScript 又は Flash オーサリングツールで定義することができる。

オブジェクトがコンテンツを理解する上で重要な語句を含んでいる場合は、name プロパティにそれらの語句を含める必要がある。これにより、name プロパティがオブジェクトと同等の機能をページ上で果たすことが可能になる。名前プロパティにはオブジェクトの見た目の特徴を記述するのではなく、オブジェクトの意味を伝える必要があることに注意する。

事例

事例 1: シンボル (グラフィック、ボタン、ムービークリップ) にテキストの代替を適用する

Flash Professional のオーサリングツールのアクセシビリティパネルを使用すると、コンテンツ制作者は、支援技術にアクセシビリティ情報を提供したり、Flash の個々のオブジェクトや Flash アプリケーション全体に対してアクセシビリティ関連オプションを設定できる。

非テキストオブジェクトにテキストによる代替を適用する際には、テキストによる代替をシンボルとしてムービーのライブラリに保存する必要がある。注記: Flash ではグラフィックシンボル用のテキストによる代替を使用することはできない。グラフィックをムービークリップまたはボタンシンボルに変換するか、これらに保存する必要がある。
アプリケーションメニューで［ウィンドウ］>［他のパネル］>［アクセシビリティ］を選択するか、ショートカットキーの Alt + F11 を使用してアクセシビリティパネルを表示する。「オブジェクトをアクセス可能にする」チェックボックスがオンになっていることを確認する。
ムービーステージ上で非テキストインスタンスを選択すると、アクセシビリティパネル内のフィールドが編集可能になる。
非テキストオブジェクトのコンテンツを簡潔に説明した文章を入力する。

画面スクリーンショット: Flash オーサリング環境のアクセシビリティパネル

事例 2: ActionScript 2.0 でプログラムによる説明を適用する

ActionScript を使用してプログラムによりオブジェクトの等価なテキストを制御するには、_accProps オブジェクトを使用する必要がある。このオブジェクトは、オブジェクトに対して設定されているアクセシビリティ関連プロパティが含まれているオブジェクトを参照する。以下に、_accProps オブジェクトを使用して ActionScript によってオブジェクトの名前と説明を設定する簡単なコード例を示す。

コード例:

// 'print_btn' は、ムービーのメインのタイムライン上に置かれたインスタンスである
_root.print_btn._accProps = new Object();
_root.print_btn._accProps.name = "印刷する";

事例 3: ActionScript 3.0 でプログラムによるテキストの代替を適用する

ActionScript 3 を使用してプログラムによりオブジェクトの等価テキストを制御するには、AccessibilityProperties オブジェクトと name プロパティを使用する必要がある。以下に、name プロパティを使用して ActionScript でオブジェクトの名前を設定する簡単なコード例を示す。

コード例:

// 'print_btn' は、ムービーのメインのタイムライン上に置かれたインスタンスである
print_btn.accessibilityProperties = new AccessibilityProperties();
print_btn.accessibilityProperties.name = "印刷する";

G94: 非テキストコンテンツに対して、それと同じ目的を果たし、かつ同じ情報を示す、簡潔なテキストによる代替を提供する

検証

手順

SWF ファイルを発行する。
Internet Explorer 6 以降 (Flash Player 6 以降を使用)、または Firefox 3 以降 (Flash Player 9 以降を使用) で SWF ファイルを開く。
オブジェクト名のテキストによる代替を表示できる ACTF aDesigner 1.0 などのツールを使用して Flash ムービーを開く。
GUI 概要パネルで、Flash ムービーに含まれている各オブジェクトをチェックし、オブジェクトに説明が設定されている場合、ツールの画面にその説明が適切に表示されることを確認する。
また、場合によってはスクリーンリーダーを使用して Flash コンテンツの読み上げをテストする。このテストでは、タブ移動の可能な非テキストオブジェクトにタブを移動したときに、そのオブジェクトの説明が読み上げられること、またはコンテンツを 1 行ずつ読み上げたときに説明が読み上げられることを確認する。
すべての非テキストオブジェクトの説明として、そのオブジェクトと同じ目的を持ち、同じ情報を伝える等価なテキストが設定されていることを確認する。

期待される結果

6. を満たしている。

FLASH2: Flash 内の非テキストオブジェクトに description プロパティを設定する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

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

FLASH2 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、元の非テキストコンテンツと同じ目的を果たし、同じ情報を提示する際に、短いテキストによる代替では不十分な場合、長いテキストによる代替を提供することを目的としている。

Flash Player は非テキストオブジェクトに対する長いテキストによる代替をサポートしている。長いテキストによる代替は ActionScript または Flash オーサリングツールで description プロパティを使用して定義することができる。以下の事例ではこの方法について説明する。

事例

事例 1: シンボル (グラフィック、ボタン、ムービークリップ) に説明を適用する

非テキストオブジェクトにテキストによる代替を適用する際には、テキストによる代替をシンボルとしてムービーのライブラリに保存する必要がある。注記: Flash ではグラフィックシンボル用のテキストによる代替を使用することはできない。グラフィックをムービークリップまたはボタンシンボルに変換するか、これらに保存する必要がある。
アプリケーションメニューで［ウィンドウ］>［他のパネル］>［アクセシビリティ］を選択するか、ショートカットキーの Alt + F11 を使用してアクセシビリティパネルを表示する。「オブジェクトをアクセス可能にする」チェックボックスがオンになっていることを確認する。
ムービーステージ上で非テキストインスタンスを選択すると、アクセシビリティパネル内のフィールドが編集可能になる。
非テキストオブジェクトのコンテンツを簡潔に説明した文章を入力する。例えば図の場合、図が伝える情報を示す「名前」を付け、「説明」フィールドには情報の完全な詳細を記述する。また、自動車の修理方法に関するムービーの一部としてアニメーションが使用されている場合、そのアニメーションの名前は「パンクしたタイヤを取り替える方法」とし、長い説明文ではその方法の詳細な手順を示すことができる。

重要: 「説明」フィールドは、オブジェクトの目的を説明するのに短いテキストによる代替では不十分な場合にのみ使用する。それ以外の場合は、「説明」フィールドは空のままにしておくこと。

画面スクリーンショット: Flash オーサリング環境のアクセシビリティパネル

事例 2: ActionScript 2.0 でプログラムによる説明を適用する

ActionScript を使用してプログラムによりオブジェクトの等価なテキストを制御するには、_accProps オブジェクトを使用する必要がある。このオブジェクトは、オブジェクトに対して設定されているアクセシビリティ関連プロパティが含まれているオブジェクトを参照する。以下に、_accProps オブジェクトを使用して ActionScript によってオブジェクトの名前と説明を設定する簡単なコード例を示す。

10 月の売上実績を示すグラフがあり、「10 月の売上実績グラフ」という短いテキストによる代替が設定されている。長い説明には、以下に示すコードによってより多くの情報を格納する。

コード例:

// 'chart_mc' は、ムービーのメインのタイムライン上に置かれたインスタンスである
_root.chart_mc._accProps = new Object();
_root.chart_mc._accProps.name = "10月の売上実績グラフ";
_root.chart_mc._accProps.description = "10月の売上実績を示す棒グラフ。\
  6名の営業がいて、マリアが最も高くて349件。その次が、フランシスで\
  301件。そして、ジュアンが256件、スーが250件、リーが200件、最後にマックスが\
  195件と続いている。棒グラフの用途は成績を示すことなので、件数の多い順に\
  紹介している。";

事例 3: ActionScript 3.0 でプログラムによる説明を適用する

ActionScript を使用してプログラムによりオブジェクトの等価なテキストを制御するには、AccessibilityProperties オブジェクトを使用する必要がある。以下に、AccessibilityProperties オブジェクトを使用して ActionScript によってオブジェクトの名前と説明を設定する簡単なコード例を示す。

コード例:

// 'chart_mc' は、ムービーのメインのタイムライン上に置かれたインスタンスである
chart_mc.accessibilityProperties = new AccessibilityProperties();
chart_mc.accessibilityProperties.name = "10月の売上実績グラフ";
chart_mc.accessibilityProperties.description = "10月の売上実績を示す棒グラフ。\
  6名の営業がいて、マリアが最も高くて349件。その次が、フランシスで\
  301件。そして、ジュアンが256件、スーが250件、リーが200件、最後にマックスが\
  195件と続いている。棒グラフの用途は成績を示すことなので、件数の多い順に\
  紹介している。";

参考リソース

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

検証

手順

SWF ファイルを発行する。
Internet Explorer 6 以降 (Flash Player 6 以降を使用)、または Firefox 3 以降 (Flash Player 9 以降を使用) で SWF ファイルを開く。
オブジェクトの長い説明を表示できる ACTF aDesigner 1.0 などのツールを使用して Flash ムービーを開く。
GUI 概要パネルで、Flash ムービーに含まれている各オブジェクトをチェックし、オブジェクトに説明が設定されている場合、ツールの画面にその説明が適切に表示されることを確認する。
また、場合によってはスクリーンリーダーを使用して Flash コンテンツの読み上げをテストする。このテストでは、タブ移動の可能な非テキストオブジェクトにタブを移動したときに、そのオブジェクトの説明が読み上げられること、またはコンテンツを 1 行ずつ読み上げたときに説明が読み上げられることを確認する。
すべての非テキストオブジェクトの説明として、そのオブジェクトと同じ目的を持ち、同じ情報を伝える等価なテキストが設定されていることを確認する。

期待される結果

6. を満たしている。

FLASH3: 支援技術によって無視されるように Flash のオブジェクトにマークを付ける

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

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

FLASH3 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法は、支援技術が無視できるように画像にマークを付ける方法を示すことである。

Flash Player では、以下の事例に示すように、アクセシビリティオブジェクトの silent プロパティを使用すると、どのグラフィックを支援技術に認識させるかをコンテンツ制作者が制御できる。

事例

事例 1: Flash Professional のオーサリングツールでグラフィックを非表示にする

グラフィックのアクセシビリティ関連プロパティに対する変更を適用するには、変更したものをシンボルとしてムービーのライブラリに保存する必要がある。注記: Flash ではグラフィックシンボル用のテキストによる代替を使用することはできない。グラフィックをムービークリップまたはボタンシンボルに変換するか、これらに保存する必要がある。
アプリケーションメニューで［ウィンドウ］>［他のパネル］>［アクセシビリティ］を選択するか、ショートカットキーの Alt + F11 を使用してアクセシビリティパネルを表示する。
グラフィックオブジェクトを選択する。
アクセシビリティパネルで「オブジェクトをアクセス可能にする」チェックボックスがオンになっている場合は、このオプションをオフにして、支援技術に伝達するアクセシビリティ情報からグラフィックを削除する。

事例 2: ActionScript 2.0 でプログラムによるテキストの代替を適用する

ActionScript を使用してプログラムによりオブジェクトの等価なテキストを制御するには、_accProps プロパティを使用する必要がある。このオブジェクトは、オブジェクトに対して設定されているアクセシビリティ関連プロパティが含まれているオブジェクトを参照する。以下に、_accProps プロパティを使用して、ActionScript を使用しているムービー用のアクセシビリティ情報からオブジェクトを削除するための簡単なコードの例を示す。

コード例:

// 'decorative_mc' は、ムービーのメインのタイムラインに置かれたインスタンスである
_root.decorative_mc._accProps = new Object();
_root.decorative_mc._accProps.silent = true;

参考リソース

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

G94: 非テキストコンテンツに対して、それと同じ目的を果たし、かつ同じ情報を示す、簡潔なテキストによる代替を提供する

検証

手順

SWF ファイルを発行する。
Internet Explorer 6 以降 (Flash Player 6 以降を使用)、または Firefox 3 以降 (Flash Player 9 以降を使用) で SWF ファイルを開く。
オブジェクトのアクセシビリティ情報を表示できる ACTF aDesigner 1.0 などのツールを使用して Flash ムービーを開く。
GUI 概要パネルで、Flash ムービーに含まれている各オブジェクトをチェックすると、表示されないように設定されているオブジェクトがツールの画面に表示されていない。
コンテンツ制作者は、テストにスクリーンリーダーを使用することもできる。その場合は、Flash コンテンツを読み上げて音声を聞くと、読み上げたページの内容にオブジェクトが含まれていない。
支援技術に無視されるようにコーディングされている非テキストオブジェクトは、支援技術からは認識できない。

期待される結果

6. を満たしている。

FLASH4: Flash で送信ボタンを提供する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 3.2.2 (入力時)
- クイックリファレンス 3.2.2 (入力時)
- 達成基準 3.2.2 (入力時)を理解する

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

FLASH4 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、コンテキストの変化を送信ボタンを使用して引き起こすようにし、送信ボタン以外のコントロールの値または状態が変更された場合はコンテキストの変化が発生しないようにすることである。この実装方法での送信ボタンの用途は、フォームに入力されたデータを送信する HTTP 要求を生成すること、またはコンテキストの変化をトリガーするアクションを実行することである (コンテキストの変化を開始するのに適したコントロールがボタンの場合)。

事例

事例 1: ActionScript 3 によるコンボボックスと送信ボタンの実装

これは、コンボボックスコンポーネントと送信ボタンによって利用者を別のリソースにリダイレクトする、ActionScript 3 の基本的な事例である。

コード例:

import fl.accessibility.ComboBoxAccImpl;
import flash.net.navigateToURL;
import flash.net.URLRequest;
ComboBoxAccImpl.enableAccessibility();
state_submit.addEventListener(MouseEvent.CLICK, submitHandler);
function submitHandler(e) {
  var url: URLRequest = new URLRequest("http://www.wikipedia.org/wiki/" + 
    state_combo.selectedLabel);
  navigateToURL(url, "_self");
}

事例 2: ActionScript 2 によるコンボボックスと送信ボタンの実装

これは、コンボボックスコンポーネントと送信ボタンによって利用者を別のリソースにリダイレクトする、ActionScript 2 の基本的な事例である。ActionScript 2 を使用していること以外は、事例 1 と同じである。

コード例:

import fl.accessibility.ComboBoxAccImpl;
ComboBoxAccImpl.enableAccessibility();
state_submit.addEventListener("click", submitHandler);
function submitHandler(e) {
  getURL("http://www.wikipedia.org/wiki/" + state_combo.selectedLabel, "_self");
}

G80: コンテキストの変化を開始する送信ボタンを提供する

検証

手順

Flash ムービー内でコンテキストの変化を開始するすべてのインタラクティブコントロールのインスタンス (送信ボタン以外) を見つける (コンボボックス、ラジオボタン、チェックボックスなど)。
それぞれのインスタンスについて、コンテキストの変化を実行するイベントハンドラが、上記のコントロール自体ではなく個別のボタンに関連付けられている。

期待される結果

2. を満たしている。

FLASH5: 同じリソースに対して隣接する画像とテキストのボタンを結合する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

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

FLASH5 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、隣接するテキストとボタンアイコンを Flash ムービーに含める際の不要な重複を回避することである。

テキストとボタンアイコンが隣接しているボタンがよく用いられている。視覚上多少離れた位置に配置するなどの目的で、テキストとアイコンボタンが個別のボタンとして表現されることも多い。視覚に問題のない利用者はこれらの位置が多少離れていることを視覚的に認識できるが、全盲やロービジョンの利用者は位置の距離を認識できないためボタンの重複に混乱する。これを避けるため、コンテンツ制作者によっては画像のアクセシブルな名前の指定を省略する場合があるが、そのような方法ではグラフィックボタンと同じ目的を果たすテキストによる代替がなくなってしまい、達成基準 1.1.1 を満たすことができない。この問題への対処として望ましいのは、テキストと画像を一つのボタンシンボルインスタンスに含め、ボタンに対して一つのアクセシブルな名前を割り当てることによってテキストの重複を回避する方法である。

事例

以下に示すのは、ステージ上の一つのボタンインスタンスに画像とテキストの両方が含まれている場合の例である。この例のテキストと画像の結合ボタンでは、「flashLink1」というインスタンス名が使用されている。

Flash Professional で結合ボタンを作成するには、次のようにする。

ステージにグラフィックオブジェクトとテキストを追加する。
両方のオブジェクトを選択する。
［挿入］メニューから「新規シンボル」を選択するか、Ctrl+F8 キーを押して、新しいボタンオブジェクトを作成する。
ステージ上のボタンオブジェクトをクリックし、プロパティパネルでインスタンス名を入力する。
さらに、以下の事例 1 から事例 3 までのそれぞれの説明に従う。

画面スクリーンショット: プロパティパネルでインスタンス名を 'flashLink1' とした結合ボタン

事例 1: アクセシビリティパネルを使用してアクセシブルな名前を指定する

アクセシビリティパネルを使用してアクセシブルな名前 (この例の場合は表示されているテキストと同じ) を指定する。

画面スクリーンショット: 結合ボタンの「名前」を記述したアクセシビリティパネル

事例 2: ActionScript を利用してアクセシブルな名前を指定する

次のように、アクセシビリティパネルの代わりに ActionScript 3 を使用して、結合ボタンのアクセシビリティ名を指定することもできる。

コード例:

// 'flashLink1' は、ムービーのメインのタイムラインに置かれたインスタンスである
flashLink1.accessibilityProperties = new AccessibilityProperties();
flashLink1.accessibilityProperties.name = "Flash についてさらに学ぶ";

また、次のように、アクセシビリティパネルの代わりに ActionScript 2 を使用して、結合ボタンのアクセシビリティ名を指定することもできる。

コード例:

// 'flashLink1' は、ムービーのメインのタイムラインに置かれたインスタンスである
flashLink1._accProps = new Object();
flashLink1._accProps.name = "Flash についてさらに学ぶ";

検証

手順

SWF ファイルを発行する。
Internet Explorer 6 以降 (Flash Player 6 以降を使用)、または Firefox 3 以降 (Flash Player 9 以降を使用) で SFW ファイルを開く。
オブジェクト名のテキストによる代替を表示できる ACTF aDesigner 1.0 などのツールを使用して Flash ムービーを開く。
ACTFaDesigner 1.0 を使用する場合は、GUI 概要パネルを使用して Flash ムービー内の各画像ボタンを確認し、画像と同じ機能を持つ別の重複したテキストコントロールが画像の近くにないことを確かめる。

期待される結果

4 を満たしている。

FLASH6: 非表示のボタンを使用してアクセシブルなホットスポットを作成する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

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

FLASH6 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、画像のクリック可能なホットスポットと同じ目的を果たすテキストによる代替を提供することである。ホットスポットというのは、アクション (例えば、ホットスポットに対応する Web ページを開くこと等) をトリガできる画像内のクリック可能な領域である。ホットスポットは、非表示の Flash ボタンとして実装し、それぞれにホットスポットのリンク先を説明するアクセシブルな名前を指定する。

事例

事例 1: アクセシブルなクリック可能領域を含むグラフィック

クリック可能なホットスポットを置く必要があるオリジナルのグラフィックをステージに追加する。
各ホットスポットについて、次の作業を行う。
1. Flash Professional の［挿入］メニューから「新規シンボル」を選択するか Ctrl + F8 キーを押して、新しいボタンシンボルを作成する。
2. ボタンシンボルの中に、クリック可能な領域に一致するシェイプを作成する。
3. 新しく作成したボタンを元のグラフィックの上に置く。
4. ボタンのプロパティパネルを開き、「カラー効果」の下にある「スタイル」ドロップダウンリストから「アルファ」を選択する。表示される「アルファ」スライダの値を 0 に変更し、ボタンを非表示にする。
5. アクセシビリティパネルを使用して「タブインデックス」フィールドの値を指定し、タブ順序内におけるボタンの論理的な位置を指定する。
6. アクセシビリティパネルを使用して、ホットスポットの目的を説明するアクセシブルな名前を指定する。

画面スクリーンショット 1: Flashのオーサリングステージにグラフィックを追加

画面スクリーンショット 2: プロパティパネルの「アルファ」スライダの値を 0 に変更して、ボタンを非表示に

画面スクリーンショット 3: アクセシビリティパネルを用いて、ボタンの名前を設定

この結果は、非表示のボタンを使用してアクセシブルなホットスポットを作成するのサンプル (英語) で確認できる。また、「非表示のボタンを使用してアクセシブルなホットスポットを作成する」のソース (英語) をダウンロードすることもできる。

G91: リンクの目的を説明したリンクテキストを提供する

検証

手順

ホットスポットが含まれるすべての画像を見つけて、各ホットスポットについて次のことを確認する。

ホットスポットが非表示のボタンとして実装されている。
アクセシビリティパネルまたは ActionScript を使用してホットスポットにアクセシブルな名前が指定されている。

期待される結果

1. および 2. を満たしている。

FLASH7: コントロールのラベルを変更するために、スクリプトを使用する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

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

FLASH7 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、前後の文脈を把握しなくても理解できるように、利用者がボタンなどのコントロールのラベルに付加情報を追加できるようにすることである。

コントロールの前後にある文脈をわざわざ把握しなくてもすむように、コントロールのラベルによって十分な情報が提供されることを望む利用者がいる。その一方で、すべてのボタンに文脈を含む情報があるのはあまりにも冗長であり、サイトの利便性を低下させると考える利用者もいる。また、支援技術の利用者からワーキンググループに寄せられるフィードバックでも、どちらが好ましいかについて意見が分かれている。この実装方法は、利用者自身が好むほうを選択できるようにするものである。

ページの先頭近くにページ上のコントロールのラベルを拡張するためのコントロールを配置し、前後の文脈を加味しなくてもコントロールの目的を理解できるようにする。必ずコントロールの目的をラベルから直接理解できるようにすることが必要である。

この実装方法によってコントロールのラベルが拡張されるのは、現在参照しているページのみである。ただし、サイト全体で 1 回選択すればすむように、cookie やサーバー側のユーザープロファイルにこの設定を保存しておく方法もある。場合によっては、そのほうが望ましいかもしれない。

事例

事例 1: ActionScript を使用してボタンのラベルに文脈の情報を直接追加する

この事例では、ActionScript を使用してボタンのラベルに文脈の情報を直接追加している。「より詳細なボタン名に変更」ボタンをクリックすることによって、ページ上の各ボタンの label プロパティが変更される。

コード例:

import fl.accessibility.ButtonAccImpl;
ButtonAccImpl.enableAccessibility();
btn1.addEventListener(MouseEvent.CLICK, clickHandler);

function clickHandler(e) {
  btn2.label = btn1.selected? "2010 年版パンフレット PDF 版": "PDF";
  btn2.width = btn1.selected? 200: 100;
  btn3.label = btn1.selected? "2010 年版パンフレット テキスト版": "Text";
  btn3.width = btn1.selected? 200: 100;
  btn4.label = btn1.selected? "2010 年版パンフレット Word 版": "Word";
  btn4.width = btn1.selected? 200: 100;
}

この結果は、ボタンのラベルにコンテキスト情報を追加するのサンプル (英語)で確認できる。また、ボタンのラベルにコンテキスト情報を追加するのソース (英語)をダウンロードすることもできる。

SCR30: リンクテキストを変更するために、スクリプトを使用する

検証

手順

Flash ムービーに前後の文脈に依存したラベルが含まれている場合、利用者がラベルに前後の文脈を加味しなくてもすむように、ラベルを拡張するためのトグルコントロールが提供されている。

期待される結果

上記手順を満たしている。

FLASH8: フォームコントロールのアクセシブルな名前 (accessible name) にグループ名を追加する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

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

FLASH8 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、関連するフォームコントロールをセマンティックにグループ化することである。これにより、利用者が複数のコントロール間の関係を理解し、より早くかつ効率的にフォームを操作することができる。

Flash では、関連するフォームコントロールがグループ化されている場合、グループの名前を各フォームコントロールのアクセシブルな名前に追加することで、そのグループを示すことができる。

コントロールのグループ化は、関係性があるラジオボタンとチェックボックスの場合に最も重要である。ラジオボタンまたはチェックボックスの一式は、それらすべてが単一の名前付きフィールドに値を送信する場合に関係性があるといえる。これらは、選択リストと同じように機能し、利用者は複数の選択肢の中からどれかを選択できる。ただし、選択リストが一つのコントロールであるのに対して、ラジオボタンやチェックボックスは複数のコントロールである点が異なる。ラジオボタンやチェックボックスは、複数のコントロールであるため、これらを意味的にグループ化して一つのコントロールとして簡単に扱えるようにすることが特に重要である。多くの場合、ユーザエージェントは、各コントロールのラベルの前にグループ名を示し、それらが同じグループのものであることを利用者に知らせる。

ラジオボタンやチェックボックスの一式ほど密接な関係性があるわけではない他のコントロール一式でも、その一式をグループ化すると便利な場合がある。例えば、利用者に住所に関する情報を入力してもらう幾つかのテキストフィールドを「住所」という名前でグループ化することができる。

事例

事例 1: ラジオボタンのアクセシブルな名前にグループ名を追加する

この事例は、グループ内のラジオボタンのグループ名を各ボタンのアクセシブルな名前に追加して、それらのグループをアクセシブルにする方法を示している。

ラジオボタンのコンポーネントをステージに追加する。
label プロパティを使用して各ボタンのラベルを入力する。
視覚的なグループラベルを手順 1 で追加したボタンの左側または上に追加する。
各ラジオボタンを選択する。アクセシビリティパネルで、「名前」フィールドにグループ名を追加する。

Flash は、「性別男性」というように、グループ名を各ボタンの個別の名前に連結する。

次のスクリーンショットは、このアプローチについて示したものである。

画面スクリーンショット: アクセシビリティパネルを用いて、フォームコントロールにグループ名を追加

注記: この事例のラジオボタンをアクセシブルにするには、次の 2 行をムービーのスクリプトに追加する必要がある。import fl.accessibility.RadioButtonAccImpl; RadioButtonAccImpl.enableAccessibility();

このアプローチの実例については、ラジオボタンのアクセシブルな名前にグループ名を追加するのサンプル (英語)を参照のこと。ラジオボタンのアクセシブルな名前にグループ名を追加するのソース (英語)をダウンロードすることもできる。

事例 2: プログラムによってラジオボタンのアクセシブルな名前にグループ名を追加する

次のコード例は、グループ名を含むフォームコントロール一式を長方形のようなフィールドセット内に配置するクラスの基本的な概念実証を示している。追加される各コントロールに対して AccessibilityProperties オブジェクトが作成され、その name プロパティが、グループ名のテキストと実際のフォームコントロールのラベルの組み合わせに設定される。

コード例:


package wcagSamples {
  import flash.display. *;
  import flash.text. *;
  import fl.controls. *
  import flash.accessibility. *;
  import fl.accessibility. *;
  
  
  /**
  *  HTMLで提供されているfieldset要素を模倣する方法を実演する基本的なサンプル。
  *  FieldSet クラスは、複数のコントロールをグループ化してfieldsetの矩形内に配置し、
  *  その先頭にグループ名となるテキストを置く。各フォームコントロールに対して、
  *  グループ名のテキストはコントロールのアクセシブルな名前の前に追加される。
  *
  *  注記: これは概念の実証を目的にしたものであり、完全に機能するクラスではない。
  *
  *  @langversion 3.0
  *  @playerversion Flash 10
  *
  */
  public class FieldSet extends Sprite {
    private var legend: String;
    private var bBox: Shape;
    private var currentY: int = 20;
    
    public static var LABEL_OFFSET_X: int = 20;
    public static var CONTROL_OFFSET_X: int = 110;
    
    /**
    *  CONSTRUCTOR
    *  Legend は、FieldSetのグループ名となるテキストを特定する
    *  itemsは、そのFieldSetに追加されるコントロールを説明する
    */
    
    public function FieldSet(legend: String, items: Array) {
       // この事例で使われているコンポーネントのアクセシビリティを有効にする
      RadioButtonAccImpl.enableAccessibility();
      CheckBoxAccImpl.enableAccessibility();
      
      //FieldSet の矩形とグループ名を生成する
      legend = legend;
      bBox = new Shape();
      bBox.graphics.lineStyle(1);
      bBox.graphics.drawRect(10, 10, 300, 250);
      bBox.graphics.beginFill(0x0000FF, 1);
      addChild(bBox);
      
      var fieldSetLegend: TextField = new TextField();
      fieldSetLegend.text = legend;
      fieldSetLegend.x = 20;
      fieldSetLegend.y = 3;
      fieldSetLegend.background = true;
      fieldSetLegend.backgroundColor = 0xFFFFFF;
      fieldSetLegend.border = true;
      fieldSetLegend.borderColor = 0x000000;
      fieldSetLegend.autoSize = TextFieldAutoSize.LEFT;
      addChild(fieldSetLegend);
      
      // コントロールを追加する
      for (var i = 0; i < items.length; i++) {
        processItem(items[i]);
      }
    }
    
    /**
    * コントロールをFieldsetに追加し、アクセシブルな名前を設定する。 
    * コントロールは配列で表されており、次の値を含んでいる。
    * [0] : コンポーネントのタイプを表す文字列 
    *   (例: "TextInput", TextArea", Checkbox" または "RadioGroup")
    * [1] : コントロールを特定するために用いられるラベル
    * [2] : もし [0] が "RadioGroup" だった場合、[2] は個々のラジオボタンに対する 
    *    ラベルの配列を含んでいる必要がある。もし [0] が "CheckBox" だった場合、 
    *    [1] は空または質問 (例:「喫煙しますか？」) のどちらかで、
    *    [2] は CheckBox のラベル (例:「はい」) となる。
    *
    */
    function processItem(item: Array) {
      if (item.length < 2)
      return;
      currentY += 30;
      var newControl;
      //create visual label
      var lbl: Label;
      lbl = new Label();
      lbl.text = item[1] + ": ";
      lbl.x = FieldSet.LABEL_OFFSET_X;
      lbl.y = currentY;
      lbl.width = FieldSet.CONTROL_OFFSET_X;
      lbl.autoSize = TextFieldAutoSize.RIGHT;
      lbl.wordWrap = true;
      addChild(lbl);
      
      switch (item[0]) {
        case "TextInput":
        case "TextArea":
        newControl = item[0] == "TextInput"? new TextInput(): new TextArea();
        newControl.x = FieldSet.CONTROL_OFFSET_X;
         //グループ名とラベルをつなげて、アクセシブルな名前にする。
        setAccName(newControl, legend + " " + item[1]);
        break;
        case "CheckBox":
        newControl = new CheckBox();
        newControl.label = item[2];
        newControl.x = FieldSet.CONTROL_OFFSET_X;
        setAccName(newControl, legend + " " + item[1] + " " + item[2]);
        break;
        case "RadioGroup":
        if (item[2] && item[2].length > 0) {
          var radioGroup: RadioButtonGroup = new RadioButtonGroup(item[0]);
          var newBtn: RadioButton;;
          for (var i = 0; i < item[2].length; i++) {
            newBtn = new RadioButton();
            // concatenate the legend, the group label, and the button label
            setAccName(newBtn, legend + " " + item[1] + " " + item[2][i]);
            newBtn.label = item[2][i];
            newBtn.group = radioGroup;
            newBtn.x = FieldSet.CONTROL_OFFSET_X;
            newBtn.y = currentY;
            addChild(newBtn);
            if (i < item[2].length - 1)
            currentY += 30;
          }
        }
        break;
      }
      
      if (newControl) {
        newControl.y = currentY;
        addChild(newControl);
      }
    }
    
    /**
     * オブジェクトに対するAccessibilityProperties オブジェクトを生成し、その name プロパティを設定する
    */
    public function setAccName(obj, accName) {
      var accProps: AccessibilityProperties = new AccessibilityProperties();
      accProps.name = accName;
      obj.accessibilityProperties = accProps;
    }
  }
}

この事例のクラスの初期化は次のように行う。

コード例:

var myFieldSet = new FieldSet("Personal Details",  // グループ名 
  [["TextInput", "名前"],                          // テキストフィールド
  ["RadioGroup", "性別", ["男性", "女性"]],          // ラジオボタンのグループ
  ["CheckBox", "喫煙しますか？", "はい"],             // チェックボックス
  ["TextArea", "コメント"],                        // テキストエリア
]);
addChild(myFieldSet);

このアプローチの実例については、プログラムによってラジオボタンのアクセシブルな名前にグループ名を追加するのサンプル (英語) を参照のこと。プログラムによってラジオボタンのアクセシブルな名前にグループ名を追加する」のソースがダウンロードできる。

注記: Adobe Flex を使用すれば、<form>, <formitem> および <formheading> 要素を使用して、このタイプの動作を実現できる。

FLASH25: アクセシブルな名前 (accessible name) を設定することによって、フォームコントロールにラベルを付ける

検証

手順

Flash ムービーにグループ化されたフォームコントロールが含まれている場合は、次のいずれかを満たしていることを確認する。

各コントロールのアクセシビリティパネルの「名前」フィールドにグループ名が含まれている。
各コントロールに AccessibilityProperties.name プロパティがあり、グループ名とコントロールのラベルとなるテキストの両方を含んでいる。

期待される結果

上記手順のいずれかを満たしている。

FLASH9: 収録済みの同期したメディアにキャプションをあてる

適用 (対象)

Adobe Flash をベースにしたコンテンツ

Adobe Flash CS3 以降

これは、次の達成基準に関連する達成方法である:

達成基準 1.2.2 (キャプション (収録済) )
- クイックリファレンス 1.2.2 (キャプション (収録済) )
- 達成基準 1.2.2 (キャプション (収録済) )を理解する

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

FLASH9 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、聴覚障害のある利用者や同期したメディア内の音声や会話を聞くことが困難な利用者が、音声情報の代替手段としてキャプションを見るように選択できるオプションを提供することである。この実装方法では、すべての会話と重要な音がテキストとして提供されるが、それらのテキストは利用者が要求した場合以外は表示されない。結果として、必要な場合にのみ表示される。これは、FLVPlayback コンポーネントと FLVPlaybackCaptioning コンポーネントを使用して実現できる。注記: FLVPlayback のスキンを使用すると、クローズドキャプションボタンがデフォルトでアクセシブルになる。ただし、カスタムスキンを実装する場合は、クローズドキャプションボタンがアクセシブルかどうかをコンテンツ制作者がテストする必要がある。

事例

事例 1: Timed Text のキャプションファイルを Flash に追加する

外部ツール (Magpie やシンプルなテキストエディタなど) を使用して、Timed Text を用いたキャプションの XML ファイルを作成する。ビデオコンテンツを停止して再生し、音声情報の適切な部分 (会話、重要な背景音、イベントサウンドなど) ごとに開始と終了のタイムコードおよびテキストの代替を挿入する。Magpie のようなツールにはこの作業を簡単に行うことができる高度な機能がある。これに対し、テキストエディタでは次のキャプション文書の例に示すようにメディアプレーヤーからタイムコードを読み取って XML に含める必要がある。
Flash では、ステージに FLVPlayback コンポーネントの新しいインスタンスを作成し、［コンポーネントインスペクタ］パネルまたは［パラメータ］パネルを使用して contentPath 値を flv ビデオファイルに設定する。
CC (クローズドキャプション) ボタンを含むスキンを使用するように「Skin」パラメータを設定する。
さらに、コンポーネントのリストから FLVPlayback キャプションコンポーネントのインスタンスを作成する。［コンポーネントインスペクタ］パネルで、「Source」パラメータを Timed Text の XML ファイルの名前に設定する。キャプションは、プレーヤーのフレームの下部に自動的に配置される。

コード例:

<?xml version="1.0" encoding="UTF-8"?>
<tt xml:lang="en" xmlns="http://www.w3.org/2006/04/ttaf1"
  xmlns:tts="http://www.w3.org/2006/04/ttaf1#styling">
  <head>
    <styling>
      <style id="defaultSpeaker" tts:backgroundColor="black"
        tts:color="white" tts:fontFamily="SansSerif" tts:fontSize="12"
        tts:fontStyle="normal" tts:fontWeight="normal"
        tts:textAlign="left" tts:textDecoration="none"/>
      <style id="defaultCaption" tts:backgroundColor="black"
        tts:color="white" tts:fontFamily="Arial" tts:fontSize="12"
        tts:fontStyle="normal" tts:fontWeight="normal"
        tts:textAlign="center" tts:textDecoration="none"/>
    </styling>
  </head>
  <body id="thebody" style="defaultCaption">
    <div xml:lang="en">
      <p begin="0:00:00.20" end="0:00:02.20">If there were nothing in
        our universe</p>
      <p begin="0:00:02.20" end="0:00:05.65">the fabric of space-time
        would be flat.</p>
      <p begin="0:00:05.65" end="0:00:08.88">But add a mass, and
        dimples form within it.</p>
      <p begin="0:00:16.61" end="0:00:19.84">Smaller objects that
        approach that large mass</p>
      <p begin="0:00:19.84" end="0:00:23.41">will follow the curve in
        space-time around it.</p>
      <p begin="0:00:32.64" end="0:00:36.84">Our nearest star, the
        sun, has formed such a dimple</p>
      <p begin="0:00:36.84" end="0:00:38.00">and our tiny planet
        Earth</p>
      <p begin="0:00:38.00" end="0:00:41.50">goes along for the ride
        in the curve of its dimple</p>
      <p begin="0:00:41.50" end="0:00:43.80">staying in orbit around
        the sun.</p>
      <p begin="0:00:45.67" end="0:01:55.00"/>
    </div>
  </body>
</tt>

この実例は、Timed Textのキャプションファイルを Flash に追加する」のサンプル (英語) で確認できる。また、Timed Textのキャプションファイルを Flash に追加する」のサンプルをダウンロードすることもできる。

参考リソース

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

http://ncam.wgbh.org/invent_build/web_multimedia/tools-guidelines

http://www.buraks.com/captionate/

http://www.w3.org/AudioVideo/TT/

G87: クローズドキャプションを提供する

検証

手順

Flash ムービーで表示されるすべてのビデオコンテンツを見て、次のことを確認する。

すべての音声コンテンツでキャプションを利用でき、デフォルトまたは利用者環境設定によってオンになる。
ビデオに含まれるすべての音声情報がキャプションで適切に説明されている。

期待される結果

1. および 2. を満たしている。

FLASH10: Flash でフォームコントロールが必須項目であることを示す

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 3.3.2 (ラベル又は説明)
- クイックリファレンス 3.3.2 (ラベル又は説明)
- 達成基準 3.3.2 (ラベル又は説明)を理解する
注記: この達成方法は、達成基準 3.3.2 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 3.3.2 を理解するを参照すること。

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

FLASH10 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、利用者がデータを正しく送信できるように、ウェブアプリケーションまたはフォームに含まれる特定のフォームコントロールが必須項目であることを明示することである。フォームコントロールのアクセシブルな名前に「必須」という語を追加し、視覚的な表示をラベルの横に配置する。

事例

事例 1: コントロールのアクセシブルな名前に「必須」という語を追加する

この事例では、アクセシビリティパネルを使用して、フィールドが「必須」であることを利用者に知らせる方法を示している。

フォームコントロールのラベルの近くに、アスタリスク文字などの視覚的なマークを配置する。
アクセシビリティパネルを使用して、「名前」フィールドに記述したコントロールのラベルのすぐ後に「(必須)」と記述する。

次のスクリーンショットは、このアプローチについて説明したものである。

画面スクリーンショット: アクセシビリティパネルを用いて、フォームコントロールが必須項目であることを明示

この実例は、コントロールのアクセシブルな名前に「必須」という語を追加するのサンプル(英語) で確認できる。また、コントロールのアクセシブルな名前に「必須」という語を追加するのソース (英語) をダウンロードすることもできる。

検証

手順

Flash ムービーに含まれる必須項目のフォームコントロールごとに、次のことを確認する。

必須項目であることが視覚的に示されている。
必須項目であることが、アクセシビリティパネルの「名前」フィールドを使用してテキストで記述されている。

期待される結果

上記の二点を満たしている。

FLASH11: オブジェクトについて長いテキストの説明を提供する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

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

FLASH11 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、画像のアクセシブルな名前として適切な、画像についての長くて詳細なテキスト情報を提供することである。画像の隣にアクセシブルなボタンを配置し、そのボタンによって画像の長いテキストの説明を含む新しいパネルを表示するようにする。

事例

事例 1: 非表示の説明を利用者の要求に応じて表示する

この事例では、統計データを含む画像が用いられている。画像には、短いテキストの代替が提供されている (「グラフ: 一つ以上の障害があることを申告した米国の施設に入っていない 16～64 歳の人口比率」)。画像の下にあるボタンを押すことによって、利用者は統計情報自体の長いテキストの説明を表示することができる。ボタンを押すと、次のように動作する。

長いテキストの説明を含むムービークリップが表示され、AccessibilityProperties.silent プロパティが false に設定され、支援技術で認識可能となる。そして、そのコンテンツがタブ順序に配置される。
元の画像とボタンは、支援技術とタブ順序からは一時的に隠された状態になる。

画像と説明テキストは、既に WebAIM.org に公開されていた HTML example for long image descriptions から引用した。

この実装方法の実例は、非表示の説明を利用者の要求に応じて表示する」のサンプル (英語) で確認できる。また、非表示の説明を利用者の要求に応じて表示するのソース (英語) をダウンロードすることもできる。

コード例:

import flash.accessibility. *;
import fl.accessibility.ButtonAccImpl;
import flash.system.Capabilities;

ButtonAccImpl.enableAccessibility();

//set accessibility properties
graph_mc.accessibilityProperties = new AccessibilityProperties();
graph_mc.accessibilityProperties.name = "Graph of percentage of total U.S. \ 
  noninsitutionalized population age 16-64 declaring one or more disabilities";
longDescBtn.accessibilityProperties = new AccessibilityProperties();
longDesc_mc.accessibilityProperties = new AccessibilityProperties();
longDesc_mc.accessibilityProperties.forceSimple = false;
hideLongDesc();

//set click handlers for button
longDescBtn.addEventListener("click", function () {
  showLongDesc()
});
longDesc_mc.longDescCloseBtn.addEventListener("click", function () {
  hideLongDesc()
});

function showLongDesc() {
  // hide the original content from screen readers
  graph_mc.accessibilityProperties.silent = true;
  graph_mc.tabEnabled = false;
  graph_mc.alpha = 0.2;
  longDescBtn.enabled = false;
  longDescBtn.accessibilityProperties.silent = true;
  longDesc_mc.accessibilityProperties.silent = false;
  // make the long description panel visible, both visually and to screen readers
  longDesc_mc.visible = true;
  longDesc_mc.tabEnabled = true;
  longDesc_mc.longDescTitle.stage.focus = longDesc_mc.longDescTitle;
  if (Capabilities.hasAccessibility)
  Accessibility.updateProperties();
}

function hideLongDesc() {
  //do the opposite to what showLongDesc does
  graph_mc.accessibilityProperties.silent = false;
  graph_mc.tabEnabled = true;
  graph_mc.alpha = 1;
  longDescBtn.enabled = true;
  longDescBtn.accessibilityProperties.silent = false;
  longDesc_mc.visible = false;
  longDesc_mc.accessibilityProperties.silent = true;
  longDesc_mc.tabEnabled = false;
  longDescBtn.stage.focus = longDescBtn;
  if (Capabilities.hasAccessibility)
  Accessibility.updateProperties();
}

検証

手順

Flash ムービーに長い説明を要する画像が含まれている場合、近くにあるボタンを押すことによって長い説明が表示される。

期待される結果

上記の手順を満たしている。

FLASH12: クライアントサイドのバリデーションを提供し、アクセシブルな説明 (accessible description) によってエラーテキストを追加する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

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

FLASH12 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、各フィールドに利用者が入力した値をクライアントサイドのスクリプトを用いてバリデートすることである。エラーが見つかった場合、無効なデータのあるコントロールにエラーメッセージが追加される。エラーメッセージは、コントロールのすぐ横に視覚的に配置される。また、エラーメッセージのテキストがコントロールのアクセシブルな「説明」に追加され、コントロールがフォーカスを受け取るときに、支援技術で読みやすくなる。

事例

事例 1: テキストフィールドのバリデート

この事例では、二つのテキストフィールド (「name」および「zip code」) を含むサンプルフォームが示されている。どちらのフィールドも必須入力である。フォームの「submit」ボタンが押されると、テキストフィールドの値が検証される。テキストフィールドに無効な値が含まれていると、_accProps オブジェクトがそのテキストフィールドに対して生成され、description プロパティにエラーメッセージが設定される。

注記: アクセシブルな「説明」(_accProps.description プロパティ) を使用する代わりに、エラーテキストをアクセシブルな「名前」(_accProps.name) に追加することもできる。これは、_accProps.description よりも広範囲の支援技術でサポートされている。

ActionScript 2.0 のコード

コード例:

import flash.accessibility. *;
import mx.accessibilty.ButtonAccImpl;
import mx.controls.Alert;
import mx.accessibility.AlertAccImpl;

AlertAccImpl.enableAccessibility();
ButtonAccImpl.enableAccessibility;

resetTextFieldAccNames();
Accessibility.updateProperties();

submit_btn.addEventListener("click", handleClick);
function handleClick(e) {
  //reset values
  resetTextFieldAccNames();
  resetTextFieldAccDescriptions();
  resetErrorLabels();
  //perform validation
  var errors =[];
  if (name_txt.text == '')
    errors.push([name_txt, "You must enter your name", name_error_lbl]);
  if (zipcode_txt.text == '')
    errors.push([zipcode_txt, "You must enter your zip code", zipcode_error_lbl]);
  else if (zipcode_txt.text.length != 5 || isNaN(zipcode_txt.text))
    errors.push([zipcode_txt, "Zip code must be 5 digits", zipcode_error_lbl]);
  
  //add validation error messages, if any
  var field, errorMsg, errorLabel;
  if (errors.length > 0) {
    //loop over encountered errors
    for (var i = 0; i < errors.length; i++) {
      field = errors[i][0];
      errorMsg = errors[i][1];
      errorLabel = errors[i][2];
      
      updateAccDescription(field, "Warning: " + errorMsg);
      errorLabel.text = errorMsg;
    }
  } else {
    Alert.show("Form field values were entered correctly");
  }
  Accessibility.updateProperties();
}

function updateAccName(obj, newName: String) {
  if (! obj._accProps)
  obj._accProps = new Object();
  obj._accProps.name = newName;
}

function updateAccDescription(obj, newDescription: String) {
  if (! obj._accProps)
  obj._accProps = new Object();
  obj._accProps.description = newDescription;
}

function getAccName(obj) {
  return obj._accProps? obj._accProps.name: "";
}

function resetTextFieldAccNames() {
  updateAccName(name_txt, "name, required");
  updateAccName(zipcode_txt, "zip code, required");
}

function resetTextFieldAccDescriptions() {
  updateAccDescription(name_txt, "");
  updateAccDesciption(zipcode_txt, "");
}

function resetErrorLabels() {
  name_error_lbl.text = "";
  zipcode_error_lbl.text = "";
}

この方法は、テキストフィールドのバリデートのサンプル(英語) で確認できる。また、テキストフィールドの検証のソース(英語) をダウンロードすることもできる。

SCR32: クライアントサイドのバリデーションを提供し、DOM を介してエラーテキストを追加する

検証

手順

Flash ムービーが送信可能でインタラクティブなフォームを提供する場合、次のことを確認する。

エラーメッセージ (アラート) が、視覚的にコントロールのすぐ隣に配置されている。
エラーメッセージ (アラート) が、コントロールのアクセシブルな「名前」または「説明」に追加されている。

期待される結果

1. および 2. を満たしている。

FLASH13: Flash コンテンツの言語を指定するために、HTML の言語属性を使用する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

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

FLASH13 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、Flash が含まれるページの HTML 要素または object 要素に lang 属性または xml:lang 属性 (またはその両方) を指定することによって、Flash コンテンツのデフォルトの言語を特定することである。埋め込まれた Flash コンテンツは、この方法で指定された言語を継承する。Web ページ全体で一つの言語を使用する場合は、ページの HTML 要素に lang 属性および xml:lang 属性を指定することができる。これについては、H57: html 要素の言語属性を用いるで説明されている。

Flash は HTML 要素または object 要素から言語を継承する。したがって、Flash コンテンツ内のすべてのテキストは、そのようにして継承された言語であると想定される。これは、ある言語のページに別の言語の Flash オブジェクトを配置すること、また、異なる言語の複数の Flash オブジェクトを配置することが可能であることを意味する。ただし、この実装方法を使用して、一つの Flash オブジェクト内でコンテンツの自然言語を変更するように指定することはできない。

事例

事例 1: 埋め込まれた Flash 内でページ全体の言語を使用する

この事例では、Web ページ全体のコンテンツをフランス語に定義する。Flash コンテンツは、HTML コンテナで指定された言語を継承する。

コード例:

<?xml version="1.0" encoding="UTF-8"?>
<html lang="fr" xml:lang="fr" xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta content="text/html; charset=iso-8859-1"
      http-equiv="Content-Type"/>
    <title>Flash Languages Examples - French</title>
    <script src="swfobject.js" type="text/javascript"/>
    <script type="text/javascript">
    swfobject.registerObject("myMovie", "9.0.115", "expressInstall.swf");
</script>
  </head>
  <body>
    <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
      height="420" id="myMovie" width="780">
      <param name="movie" value="myMovie.swf"/>
      <!--[if !IE]>-->
      <object data="languages.swf" height="420"
        type="application/x-shockwave-flash" width="780">
        <!--<![endif]-->
        <!--[if !IE]>-->
      </object>
      <!--<![endif]-->
    </object>
  </body>
</html>

この実例は、埋め込まれた Flash 内でページ全体の言語を使用するのサンプル (英語) で確認できる。また、埋め込まれた Flash 内でページ全体の言語を使用するのソース (英語) をダウンロードすることもできる。

事例 2: 埋め込まれた Flash のみに言語を適用する

この事例では、Flash ムービーのコンテンツをフランス語に定義する。Flash ムービーは、SWFObject's SWFObject による静的なパブリッシュ手法 (英語) を使用して埋め込まれている。この手法では二つのネストした object 要素が使用され、外側の要素は Internet Explorer 向け、内側の要素はその他のブラウザ向けである。このため、lang 属性および xml:lang 属性を二つ追加する必要がある。

コード例:

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
  height="420" id="myMovie" lang="fr" width="780" xml:lang="fr">
  <param name="movie" value="myMovie.swf"/>
  <!--[if !IE]>-->
  <object data="languages.swf" height="420" lang="fr"
    type="application/x-shockwave-flash" width="780" xml:lang="fr">
    <!--<![endif]-->
    <!--[if !IE]>-->
  </object>
  <!--<![endif]-->
</object>

参考リソース

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

検証

手順

SWF への参照が含まれている HTML ドキュメントの html 要素および object 要素を確認する。
Flash コンテンツの言語 (人間が使用する言語) が、object 要素で継承されている言語 (HTML 4.01 仕様書の「Inheritance of language codes」を参照) と同じである
lang 属性の値が、「BCP 47: Tags for the Identification of Languages」、またはその後続の仕様に準拠しており、Flash コンテンツで使用されている主要言語を反映したものである。
Flash コンテンツ内で人間が使用する言語に変更が生じていない

期待される結果

達成基準 3.1.1 については、1.～3. を全て満たしている。
達成基準 3.1.2 については、1.～4. を全て満たしている。

FLASH14: Flash でキーボード及びマウスのイベントハンドラを両方とも使用する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 2.1.1 (キーボード)
- クイックリファレンス 2.1.1 (キーボード)
- 達成基準 2.1.1 (キーボード)を理解する
注記: この達成方法は、達成基準 2.1.1 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 2.1.1 を理解するを参照すること。
達成基準 2.1.3 (キーボード (例外なし) )
- クイックリファレンス 2.1.3 (キーボード (例外なし) )
- 達成基準 2.1.3 (キーボード (例外なし) )を理解する
注記: この達成方法は、達成基準 2.1.3 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 2.1.3 を理解するを参照すること。

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

FLASH14 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、マウスイベント、フォーカスイベントそれぞれに対応するイベントハンドラを指定することによって、デバイスに依存しない操作を提供する方法を示すことである。マウスイベントとキーボードイベントの両方をサポートすることにより、利用者は使用している入力デバイスに関係なく、同じ情報を受け取ることができるようになる。イベントによってコントロールの状態が変更される場合は、イベントハンドラ内でコントロールの説明的な名前を変更することが重要になる場合がある。

事例

事例 1: 複数のイベントハンドラを使用してボタンのテキストを更新する

この事例では、ボタンのグループに対して、flash.events.FocusEvent.FOCUS_IN イベントと flash.events.MouseEvent.MOUSE_OVER イベントに同じイベントハンドラを割り当てている。ボタンがフォーカスを受け取るか、またはマウスをボタンの上に移動すると、ボタンを説明するテキストが更新される。

コード例:

import fl.accessibility.ButtonAccImpl;
import fl.controls.Button;
import flash.accessibility. *
import flash.events.FocusEvent;
import flash.events.MouseEvent;
import flash.net.navigateToURL;
import flash.net.URLRequest;

ButtonAccImpl.enableAccessibility();
var states: Object = {
  "Alabama": "Alabama is a state located in the southeastern region of the \
    United States of America.",
  "California": "California is the most populous state in the United States",
  "New York": "New York is a state in the Mid-Atlantic and Northeastern \
    regions of the United States"
};

var buttons: Array =[];
var button: Button;
var accProps: AccessibilityProperties;
var count = 0;
for (var i in states) {
  button = new Button();
  button.label = i;
  button.addEventListener(MouseEvent.CLICK, clickHandler);
  button.addEventListener(MouseEvent.MOUSE_OVER, highlightHandler);
  button.addEventListener(MouseEvent.MOUSE_OUT, unHighlightHandler);
  button.addEventListener(FocusEvent.FOCUS_IN, highlightHandler);
  button.addEventListener(FocusEvent.FOCUS_OUT, unHighlightHandler);
  accProps = new AccessibilityProperties();
  accProps.description = states[i];
  button.accessibilityProperties = accProps;
  addChild(button);
  button.x = 30
  button.y = 30 + count * 30;
  buttons[i] = button;
  count++;
}

function highlightHandler(e) {
  descText.text = states[e.target.label];
}

function unHighlightHandler(e) {
  descText.text = "";
}


function clickHandler(e) {
  var url: URLRequest = new URLRequest("http://www.wikipedia.org/wiki/" + e.target.label);
  navigateToURL(url, "_self");
}

注記: スクリーンリーダーを使用している利用者のアクセシビリティを向上させるには、説明文のテキストをアクセシブルな説明としてボタン自体に付加する。また、ボタンコンポーネントの MouseEvent.CLICK イベントは、マウスクリックだけではなく Enter キーを押したときにも発生することに注意しなければならない。

この実装方法は、複数のイベントハンドラを使用してボタンのテキストを更新するのサンプル (英語) で確認できる。また、複数のイベントハンドラを使用してボタンのテキストを更新するのソース (英語) をダウンロードすることもできる。

SCR2: キーボード及びマウスのイベントハンドラを両方とも使用する

検証

手順

Flash ムービーのスクリプト内のすべてのイベントハンドラについて、次の手順を実行する。

マウスとキーボードの両方のイベントにイベントハンドラが割り当てられている

期待される結果

1. を満たしている。

FLASH15: Flash 内の論理的な読み上げ順序及びタブ順序を指定するために、tabIndex プロパティを使用する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

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

FLASH15 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、Flash ムービー内の各要素にタブインデックス (tabIndex) 値を割り当てることによって音声読み上げ順序を制御することである。

タブ順序とは、利用者が Tab キーを押したときに、オブジェクトが入力フォーカスを受け取る順序である。音声読み上げ順序にフォーカスを受け取ることのできない要素が含まれているのと同様に、タブ順序には必ずしも音声読み上げ順序と同じ要素が含まれているわけではない。しかし、音声読み上げ順序とタブ順序は、どちらもタブインデックスの値を用いて制御することが可能である。

Flash Player では、デフォルトのタブインデックスの順序 (左から右、上から下) が使用される。

カスタムの読み上げ順序を作成するには、ActionScript またはアクセシビリティパネルを使用して、ステージ上の各インスタンスにタブインデックス値を割り当てる。フォーカスを受け取ることが可能なオブジェクトだけではなく、アクセシビリティが有効なすべてのオブジェクトに対して tabIndex 値を作成する。例えば、利用者はダイナミックテキストにタブ移動することはできないが、ダイナミックテキストもタブインデックスを持つ必要がある。

キーボード操作のナビゲーションのために、次のオブジェクトに対して、アクセシビリティパネルを使用してカスタムのタブインデックス値を指定することができる。

ダイナミックテキスト
入力テキスト
ボタン
ムービークリップ (コンパイルしたムービークリップを含む)
コンポーネント
スクリーン

Tab キーによるフォーカス移動は、タブインデックス値の最も小さいところからスタートする。Tab キーによるフォーカス移動が最も大きなタブインデックス値のオブジェクトに達すると、フォーカスはまた最も小さいタブインデックス値のオブジェクトに戻る。タブインデックス値が指定されているオブジェクトをドキュメント内または別のドキュメントへ移動させる際には、Flash はタブインデックス属性値を保持している。そのため、タブインデックス値の重複 (例えば、ステージ上にある二つの異なるオブジェクトが同じタブインデックス値を持っていないか) をチェックして、必要に応じて修正する必要がある。フレーム内の複数のオブジェクトに同じタブインデックス値が設定されている場合は、Flash はオブジェクトがステージ上に配置された順序に従う

アクセシビリティパネルを使用してタブインデックス値を追加するには、ステージ上のアクセシビリティが有効なすべてのオブジェクトに対して以下の手順を実行する。

要素をクリックして選択する。
アクセシビリティパネルで、「タブインデックス」フィールドに数値を入力する。この値には、選択されているオブジェクトの読み上げ順序を示す正の整数 (最大 65535) を指定する必要がある。タブインデックスに小さい値が設定された要素が先に、大きい値が設定された要素が後に読み上げられる。フレーム内の複数のオブジェクトに同じタブインデックスが設定されている場合は、Flash はオブジェクトがステージ上に配置されている順序に従う。
現在定義されているタブ順序を表示するには、［表示］>［タブ順序の表示］を選択する。個々のオブジェクトの左上にタブインデックスの数値が表示される。

注記: ActionScript のコードを用いて、キーボード操作のナビゲーションのためにタブ順序のインデックスを作成することもできる。

上記の手順を以下のスクリーンショットで示す。

画面スクリーンショット: タブ順序を視覚化

画面スクリーンショット: アクセシビリティパネルでタブインデックス値を設定

注記: 現在の Flash Player では、FLA ファイル内のすべてのオブジェクトをタブインデックス値のリストに追加する必要はない。すべてのオブジェクトにタブインデックスを指定しなくても、スクリーンリーダーは各オブジェクトを正しく読み上げる。

事例

事例 1: タブインデックスを使用して列の構造をナビゲートする

この事例には、列としてグループ化された動的な TextField インスタンスが含まれている。列の構造に従って読み上げ順序が設定されるようにする。TextField インスタンスには、テキストコンテンツに応じたタブインデックス値が指定されている (例えば、テキスト「Sample text 3」が格納されている TextField にはタブインデックス値 3 が設定されている)。また、タブインデックス値を設定していない TextField が一つ追加されている。このフィールドには、テキスト「Not in tab order」が格納されている。このフィールドは見かけ上は「Sample text 2」と「Sample text 3」の間に配置されているが、タブインデックス値が割り当てられていないため、カスタムタブ順序の中では最後に配置される。

この実例は、タブインデックスを使用して列の構造をナビゲートするのサンプル (英語) で確認できる。また、タブインデックスを使用して列の構造をナビゲートするのソース (英語) をダウンロードすることもできる。

事例 2: 2 カラムレイアウトでタブ順序を制御する

この事例では、Flash ベースのフォームが 2 カラムでレイアウトされている。タブ順序がカラム構造に従うようにするには、アクセシビリティパネルを用いて各フォームコントロールにタブインデックス値を割り当てる。

この実例は、2 カラムレイアウトでタブ順序を制御するのサンプル (英語) で確認できる。また、2 カラムレイアウトでタブ順序を制御するのソース (英語) をダウンロードすることもできる。

参考リソース

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

Flash glossary: Tab order

検証

手順

スクリーンリーダーを使用して Flash ムービーの各要素を一つずつ操作する。
スクリーンリーダーがコンテンツを読み上げる順序が、視覚的な論理構造に基づいた順序と一致している。
Flash ムービー内にフォーカスが置かれているとき、Tab キーを繰り返し押すことによってキーボード操作でコンテンツ間を行き来する。
インタラクティブでフォーカスを受け取ることのできる要素すべてに、キーボード操作によってフォーカスを論理的な順序で移動させることができる。

期待される結果

2. および 4. を満たしている。

FLASH16: 標準コンポーネント上のクリックイベントを使用して、操作をキーボード操作可能にする

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 2.1.1 (キーボード)
- クイックリファレンス 2.1.1 (キーボード)
- 達成基準 2.1.1 (キーボード)を理解する
注記: この達成方法は、達成基準 2.1.1 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 2.1.1 を理解するを参照すること。
達成基準 2.1.3 (キーボード (例外なし) )
- クイックリファレンス 2.1.3 (キーボード (例外なし) )
- 達成基準 2.1.3 (キーボード (例外なし) )を理解する
注記: この達成方法は、達成基準 2.1.3 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 2.1.3 を理解するを参照すること。

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

FLASH16 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、Adobe Flash Profressional のオーサリングツールにより提供されるキーボード操作が可能な標準 Flash コンポーネントに関連付けることで、キーボード操作でスクリプト機能を呼び出す方法を示すことである。スクリプトで記述されたアクションをキーボードから呼び出せるようにするため、アクションを Button コンポーネントなどの標準的な Flash コンポーネントに関連付ける。これらのコンポーネントのクリックイベントは、デバイスに依存しない。"CLICK"イベントがマウスイベントである場合、このイベントは実際にボタンのデフォルトのアクションにマッピングされる。利用者がマウスで要素をクリックするとデフォルトのアクションが実行されるが、利用者が要素にフォーカスを移動してスペースキーを押した場合やアクセシビリティ API により要素がトリガされた場合も、デフォルトのアクションが実行される。

事例

事例 1: ボタンのクリックイベント

この事例では、MouseEvent.CLICK イベントを使用してそのラベルを変更するボタンを示している。このイベントは、マウスをクリックするかスペースキーを押した場合にトリガされる。

コード例:

import fl.controls.Button;
import fl.accessibility.ButtonAccImpl;

ButtonAccImpl.enableAccessibility();

var testBtn = new Button();
testBtn.label = "click me";
testBtn.addEventListener(MouseEvent.CLICK, clickHandler, false);
addChild(testBtn);
testBtn.x = testBtn.y = 10;

function clickHandler(e) {
  e.target.label = "Thanks";
}

この実例は、ボタンのクリックイベントのサンプル (英語) で確認できる。また、ボタンのクリックイベントのソース (英語) をダウンロードすることもできる。

事例 2: (作成中)

SCR35: アンカー及びボタンの onclick イベントを用いて、アクションをキーボード操作可能にする

検証

手順

Flash ムービーにインタラクティブなコントロールが含まれている場合は、次のことを確認する。

コントロールに標準の Flash コンポーネントが使用されている。
コントロールで "click" イベントを使用している。

期待される結果

1. および 2. を満たしている。

FLASH17: Flash オブジェクトにキーボードアクセスを提供して、キーボードトラップを回避する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 2.1.1 (キーボード)
- クイックリファレンス 2.1.1 (キーボード)
- 達成基準 2.1.1 (キーボード)を理解する
注記: この達成方法は、達成基準 2.1.1 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 2.1.1 を理解するを参照すること。
達成基準 2.1.2 (キーボードトラップなし)
- クイックリファレンス 2.1.2 (キーボードトラップなし)
- 達成基準 2.1.2 (キーボードトラップなし)を理解する
達成基準 2.1.3 (キーボード (例外なし) )
- クイックリファレンス 2.1.3 (キーボード (例外なし) )
- 達成基準 2.1.3 (キーボード (例外なし) )を理解する
注記: この達成方法は、達成基準 2.1.3 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 2.1.3 を理解するを参照すること。

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

FLASH17 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、キーボードフォーカスがウェブページに埋め込まれた Flash コンテンツに入ったり、Flash コンテンツから出たりできるようにすることである。Internet Explorer 以外のブラウザでは、埋め込まれた Flash コンテンツのキーボードアクセシビリティに関連した問題がある。その問題とは、Flash コンテンツとその周囲の HTML コンテンツのいずれもキーボードでアクセスが可能な場合、マウスを使用せずに Flash コンテンツと HTML コンテンツの間でキーボードフォーカスを移動させることができない点である。つまり、Flash コンテンツの内部にフォーカスがあると、キーボードの利用者はフォーカスを移動できない。同様に、HTML コンテンツ (Flash ムービーの外部) のいずれかにフォーカスがあると、Flash コンテンツにフォーカスを移動することができなくなる。

これは長い間存在している問題であり、ブラウザによる埋め込みプラグインの実装方法に関連している。この問題が修正されるまで、回避策を用意するのは Flash 開発者の義務である。この実装方法は、その回避策の一つである。この実装方法の背景にある考え方は以下のとおりである。

ドキュメント内の各 Flash コンテンツに関して、隣接する二つのフォーカス可能な HTML オブジェクト (コンテンツの前後のオブジェクト) を特定する。これらの要素は、ウェブページ内でタブ順序が適用される任意の HTML 要素である (リンクやフォームコントロールなど)。
Flash コンテンツのオブジェクト自体をドキュメントのタブ順序にも追加する。これにより、コンテンツにタブを移動することが可能になる。
Flash コンテンツの内部では、Flash Player が独自のタブ順序を管理する。通常、Flash コンテンツの中をタブ移動していて、タブ順序の先頭または最後に到達したとき、フォーカスはラップされて　Flash コンテンツのタブ順序の反対側の先頭または最後に移動する。つまり、フォーカスを Tab キー (または Shift + Tab キー) によって Flash コンテンツから抜け出させることができない。しかし、この実装方法を使用することによって、「フォーカスのラップ」が検出された場合に HTML のタブ順序内の隣接する要素に移動するようになる (キーボードを使用して Flash コンテンツのタブ順序から抜け出すことが可能になる)。

Flash プロジェクトに SWFFocus クラスをインポートすると、次のようになる。

JavaScript の <script> タグが生成され、Flash コンテンツが格納されている HTML ドキュメントに追加される。この JavaScript コードは以下の処理を行う。
- ページ内の各 Flash コンテンツの <object> 要素に対して、タブインデックス値 "0" を設定する。これにより、Flash オブジェクトがタブ順序に含まれるようになる。
- オプションで、Flash コンテンツの前後に非表示のアンカー要素を作成する。この要素は、SWFFocus によってフォーカスを Flash コンテンツから HTML ページに戻すために使用される。または、開発者自身が、既存のフォーカス可能な HTML 要素を Flash コンテンツの前後のタブストップとして指定することもできる。
- Flash コンテンツのオブジェクトのイベントハンドラを設定する。これによって、Flash コンテンツのオブジェクトがフォーカスを受け取った際に SWFFocus クラスに通知され、Flash コンテンツ内部のタブ順序を管理できるようにする。
SWFFocus クラスは Flash コンテンツ内のフォーカスの変更を監視する。コンテンツ内でフォーカスのラップが検出されたら JavaScript の関数が呼び出され、これによって隣接する HTML コンテンツにフォーカスが戻される。

上記で示したように、このテクニックの使用方法は二通りある。

HTML のタブ順序内で各 Flash コンテンツに隣接するフォーカス可能な要素を、SWFFocus クラスに生成させる (下記の事例 1 で示す)。
デフォルトでは、SWFFocus クラスは埋め込まれた Flash コンテンツの前後に非表示のリンク要素を作成する。これらの要素は、Flash コンテンツの外部にタブ移動 (または shift キーを押しながらタブ移動) する際に、フォーカスを移動するための「アンカー」として必要になる。この手法は、開発者による追加作業が必要ないため実装が最も簡単である。この手法の欠点は、非表示のリンクという意味のない要素が HTML のタブ順序の中に紛れ込むことである (これらの要素は、Flash コンテンツの外部にタブ移動する際のタブストップのみとして使用される。Flash コンテンツの内部にタブ移動する場合には使用されない)。以上の点から、この手法ではなく次の 2. の手法を使用することが推奨される。
HTML のタブ順序内における各 Flash コンテンツの前後のフォーカス可能な HTML 要素を明示的に指定する (下記の事例 2 で示す)。
この手法では、開発者は ID 値を使用することによって、HTML のタブ順序内で Flash コンテンツの前後に当たる要素を指定できる。これは、Flash コンテンツの <object> 要素に特別なクラス名を設定することによって実現される。タブ順序内に不必要な要素が入り込むことがないため、この手法を用いることがより好ましい。ただし、開発者自身がこの点を意識して追加作業を行う必要がある (ID 値を手動で設定する必要がある)。また、状況によっては、Flash コンテンツの前後にフォーカス可能な要素が存在しない場合もありうる。

事例

Flash オブジェクトをキーボードで操作可能にして、キーボードトラップを回避する」のサンプル (英語) でこれらの二つの事例が示されている。このサンプルの HTML ファイルには二つの Flash コンテンツが埋め込まれている。最初の Flash コンテンツは事例 1 で説明されている手法によって埋め込まれており、二つ目の Flash コンテンツは事例 2 で説明されている手法によって埋め込まれている。Flash オブジェクトをキーボードで操作可能にして、キーボードトラップを回避する」のソース (英語) をダウンロードすることもできる。ソースの zip ファイルには SWFFocus クラスが含まれている。

注記: このサンプルをウェブサーバーからではなく、ローカルドライブから実行するには、Flash Player のセキュリティ設定にローカルディレクトリを追加する必要がある。

事例 1: 自動生成されるリンクを使用する

この事例では、フォーカス可能な HTML 要素を明示的に指定することなく、SWFFocus クラスを使用している。SWFFocus によって、Flash コンテンツの前後に非表示のリンクが動的に挿入される。

Flash コンテンツをロードする

この事例では、Flash オブジェクトは SWFObject's SWFObject による動的なパブリッシュ手法 (英語) によって追加されている。この手法では、JavaScript (ブラウザによってサポートされる方法) により動的に object タグが生成される。これは推奨される手法ではあるが、この実装方法を使用することは必須ではない。なお、HTML ドキュメント内に object タグがハードコーディングされている場合であっても SWFFocus クラスは動作する。

以下のサンプルコードは、SWFObject を使用して動的にコンテンツをロードする方法を示している。

事例 1 の HTML および Javascript のサンプルコード

コード例:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Keyboard Trap Fix Example</title>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type"/>
    <script src="swfobject_2_1.js" type="text/javascript"/>
    <script type="text/javascript">
      var flashvars = {};
      var params = {};
      params.scale = "noscale";
      var attributes = {};
      attributes.id = "FlashSample1SWF";
      attributes.name = "FlashSample1SWF";
      swfobject.embedSWF("keyboard_trap_fix_custom_as3.swf", "flashSample1", \
          "150", "200", "9.0.0", "expressInstall.swf", flashvars, params, attributes);
</script>
  </head>
  <body>
    <p>The following Flash content automatically generates invisible
      links before and after the flash content, allowing keyboard focus
      to move out of the Flash content.</p>
    <div id="flashSample1">
      <a href="http://www.adobe.com/go/getflashplayer">
        <img alt="Get Adobe Flash player"
          src="http://www.adobe.com/images/shared/download_buttons/get_flash_player.gif"
        />
      </a>
    </div>
  </body>
</html>

Flash 内に SWFFocus クラスをインポートし初期化する

Flash プロジェクトのソースパスに SWFFocus クラスを追加する必要がある。これを行うための最も簡単な方法は、com/swffocus/SWFFocus.as ファイル (ネストしたディレクトリ構造も含む) をプロジェクトのルートディレクトリにコピーすることである。

コンテンツのソースパスに SWFFocus クラスを追加したら、以下のコードによってこのクラスを初期化する必要がある。

コード例:

import com.adobe.swffocus.SWFFocus;
SWFFocus.init(stage);

このクラス自身のコードはソースファイル内にある。

事例 2: 既存のフォーカス可能な HTML の要素を明示的に指定する

この実装方法の大部分は事例 1 と同じである。

SWFObject による動的ロードの手法を使用して Flash コンテンツをロードする。
コンテンツのソースパスに SWFFocus クラスを追加し、Flash コンテンツ内で初期化する必要がある。

これらの手順の詳細については、事例 1 を参照のこと。

しかし、このケースでは、Flash コンテンツのオブジェクトに特別なクラス名が追加される。これらのクラス名は、HTML のタブ順序においてコンテンツの前後に置かれる要素の ID 値を示す。このクラス名は以下のようになる。

'swfPref-<previous ID>'。この '<previous element>' にはタブ順序における前の要素の ID 値が設定される。
'swfNext-<next ID>'。この '<next element>' にはタブ順序における次の要素の ID 値が設定される。

以下に HTML コードの例を示す (object タグに追加されたクラス名に注目)。

コード例:

<a href="http://www.lipsum.com/" id="focus1">test 1</a>
<object class="swfPrev-focus1 swfNext-focus2"
  data="keyboard_trap_fix_as3.swf" tabindex="0"
  type="application/x-shockwave-flash"/>
<a href="http://www.lipsum.com/" id="focus2">test 2</a>

この事例では SWFObject の動的ロードが使用されているため、このクラス名は SWFObject の初期化時に属性として指定される必要がある。次のコード例はこの処理を示したものである。

事例 2 の HTML および Javascript のサンプルコード

コード例:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Keyboard Trap Fix Example </title>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type"/>
    <script src="swfobject_2_1.js" type="text/javascript"/>

    <script type="text/javascript">
      var flashvars = {};
      var params = {};
      params.scale = "noscale";
      var attributes = {};
      attributes.id = "FlashSample2SWF";
      attributes.name = "FlashSample2SWF";
      attributes["class"] = "swfPrev-focus1 swfNext-focus2";
      swfobject.embedSWF("keyboard_trap_fix_as3.swf", "flashSample1", "150", 
        "200", "9.0.0", "expressInstall.swf", flashvars, params, attributes);
    </script>
  </head>
  <body>
    <a href="http://www.lipsum.com/" id="focus1">lorem</a>
    <p>The following Flash content uses existing links in the document
      to move focus to when (shift) tabbing out of the Flash content.
      The existing links are defined by placing special classnames on
      the Flash object.</p>
    <div id="flashSample2">
      <a href="http://www.adobe.com/go/getflashplayer">
        <img alt="Get Adobe Flash player"
          src="http://www.adobe.com/images/shared/download_buttons/get_flash_player.gif"
        />
      </a>
    </div>
    <a href="http://www.lipsum.com/">lorem</a>
  </body>
</html>

注記: この事例では、Flash コンテンツの挿入で SWFObject が呼び出される時点で、フォーカス可能な HTML 要素が既に存在し、ID 値が設定されているものと想定している。ただし、Flash コンテンツが作成される時点ではまだこれらの要素が存在しないこともありうる。また、後になってこれらの要素が動的に削除されることもありうる。こうした状況であっても、前後のフォーカス可能な要素に ID 値の再割り当てを行うことで対応できる。これを行うには、Flash コンテンツのオブジェクト上で SWFsetFocusIds() メソッドを呼び出す。以下にその例を示す。

コード例:

var o = document.getElementById("FlashSample1SWF");
o.SWFsetFocusIds('prevId', 'nextId');

以降は、Flash コンテンツの外部にタブ移動する際にフォーカスを移動するために、更新された ID が使用される。

参考リソース

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

Example source containing the SWFFocus class
Flash and keyboard access across browsers by Henny Swan

検証

手順

ウェブページ上の Flash コンテンツについて:

可能であれば、Flash コンテンツのソースが SWFFocus クラスをインポートし、初期化している。
Tab キーを押してページ上のタブ移動可能なアイテム間を移動する。
Flash コンテンツの内部にタブ移動できる。
さらに Tab キーを押し、Flash コンテンツの外部にタブ移動できる。

期待される結果

3. および 4. を満たしている。

FLASH18: Flash で自動的に再生される音声をオフにするコントロールを提供する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.2 (音声の制御)
- クイックリファレンス 1.4.2 (音声の制御)
- 達成基準 1.4.2 (音声の制御)を理解する

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

FLASH18 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、Flash ムービーの読み込み時に自動的に開始される音声を、利用者がオフにできるようにすることである。音声をオフにするコントロールは、利用者が素早く簡単に見つけられるようにページの先頭近くに置く必要がある。これは、スクリーンリーダー、画面拡大ソフト、スイッチメカニズムなどの支援技術を利用する利用者にも利用しない利用者 (認知障害、学習障害、言語障害のある利用者) にも役立つ。

この実装方法では、自動的に再生される音声を利用者がオフにできるようにするコントロールをコンテンツ制作者が実装する。アクセシビリティを最大化するためには、 Flash ムービーではなく HTML 文書にコントロールを追加する。HTML コントロールは、ExternalInterface クラスを通じて Flash ムービーと通信する。つまり、利用者は Flash コンテンツを操作しなくても、音声の再生を制御できるということである。実際のコンテンツでこの方法が適していない場合は、Flash コンテンツの内部にコントロールを配置することができる。その場合、このコントロールはキーボードで操作できるようにし、またタブ順序と読み上げ順序の最初に配置し、再生中の音声をオフにできることを明確に示すラベルを付ける。

事例

事例 1: Flash 内に音声を停止するボタンを提供する

この事例は、利用者が音声の再生を停止できるように Flash ムービーの内部にボタンを実装する方法を示している。ムービーがロードされると自動的に mp3 ファイルの再生を開始する、SoundHandler というクラスが作成される。

コード例:

package wcagSamples {
  import flash.display.Sprite;
  import flash.net.URLRequest;
  import flash.media.Sound;
  import flash.media.SoundChannel;
  
  import fl.controls.Button;
  import fl.accessibility.ButtonAccImpl;
  
  import flash.events.MouseEvent;
  public class SoundHandler extends Sprite {
    private var snd: Sound = new Sound();
    private var button: Button = new Button();
    private var req: URLRequest = new URLRequest("http://av.adobe.com/podcast\
      /csbu_dev_podcast_epi_2.mp3");
    private var channel: SoundChannel = new SoundChannel();
    
    public function SoundHandler() {
      ButtonAccImpl.enableAccessibility();
      button.label = "Stop Sound";
      button.x = 10;
      button.y = 10;
      button.addEventListener(MouseEvent.CLICK, clickHandler);
      this.addChild(button);
      snd.load(req);
      channel = snd.play();
    }
    private function clickHandler(e: MouseEvent): void {
      if (button.label == "Stop Sound") {
        button.label = "Start Sound";
        channel.stop();
      } else {
        channel = snd.play();
        button.label = "Stop Sound";
      }
    }
  }
}

この実例は、Flash 内に音声を停止するボタンを提供するのサンプル (英語) で確認できる。また、Flash 内に音声を停止するボタンを提供するのソース (英語) をダウンロードすることもできる。

事例 2: Flash オブジェクトの前に音声を停止するボタンを提供する

ムービーがロードされると自動的に mp3 ファイルの再生を開始する、SoundHandler というクラスが作成される。HTML のボタンは、Flash ムービーを含む HTML 文書に配置される。このボタンをクリックすると、Flash Player JavaScript API を通じて HTML ページと Flash ムービーの間でアクションが通知され、その結果として SoundHandler クラスの toggleSound メソッドが呼び出される。

事例 2 の ActionScript 3.0 のコード

コード例:

package wcagSamples {
  import flash.display.Sprite;
  import flash.external.ExternalInterface;
  import flash.net.URLRequest;
  import flash.media.Sound;
  import flash.media.SoundChannel;
  
  import flash.events.MouseEvent;
  public class SoundHandler extends Sprite {
    private var snd: Sound = new Sound();
    private var soundOn: Boolean = true;
    private var req: URLRequest = new URLRequest("http://av.adobe.com/podcast/\
      csbu_dev_podcast_epi_2.mp3");
    private var channel: SoundChannel = new SoundChannel();
    
    public function SoundHandler() {
      if (ExternalInterface.available)
      ExternalInterface.addCallback("toggleSound", this.toggleSound);
      snd.load(req);
      channel = snd.play();
    }
    
    private function toggleSound(enable: Boolean): void {
      if (! enable) {
        channel.stop();
        soundOn = true;
      } else {
        channel = snd.play();
        soundOn = true
      }
    }
  }
}

事例 2 の HTML コード

コード例:

<?xml version="1.0" encoding="UTF-8"?>
<!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">
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"/>
    <title>Flash Sound Toggle example</title>
    <script src="swfobject.js" type="text/javascript"/>
    <script type="text/javascript">
    function $(id) {
        return document.getElementById(id);
    }
    
    swfobject.embedSWF("html_control_to_toggle_audio_as3.swf", 
      "flashPlaceHolder", "0", "0", "8");
    function init() {
            var soundOn = true;
            $("soundToggle").onclick = function(event){
                soundOn = !soundOn;
                $("flashPlaceHolder").toggleSound(soundOn);
                event.target.value = soundOn ? "Stop Sound" : "Start Sound";
            };
    }
    window.onload = init;
</script>

  </head>
  <body id="header">
    <h1>Flash Automatic Sound Demo</h1>
    <p>This page contains a Flash movie that automatically starts
      playing sound. Use the button below to stop or start the
      sound</p>
    <input id="soundToggle" type="button" value="Stop Sound"/>
    <p id="flashPlaceHolder">Flash needs to be installed for this
      example to work</p>
  </body>
</html>

この実例は、Flash オブジェクトの前に音声を停止するボタンを提供する」のサンプル (英語) で確認できる。また、Flash オブジェクトの前に音声を停止するボタンを提供する」のソース (英語) をダウンロードすることもできる。

G170: 自動的に再生される音声を停止するコントロールを、ウェブページの先頭付近で提供する

検証

手順

ロード後に自動的に音声の再生を開始する Flash ムービーについて:

ドキュメントのタブ順序の先頭にアクセシブルな HTML コントロールが配置されている。
HTML ベースのコントロールがない場合は、Flash ムービーのタブ順序の先頭にアクセシブルなコントロールが配置されている。
HTML コントロールまたは Flash ベースのコントロールを操作する。
音声の再生が停止される。

期待される結果

1. 又は 2. を満たしていて、かつ 4. を満たしている。

FLASH19: 利用者に制限時間が間もなく終了することを警告して、制限時間を延長する方法を提示するスクリプトを提供する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.1 (タイミング調整可能)
- クイックリファレンス 2.2.1 (タイミング調整可能)
- 達成基準 2.2.1 (タイミング調整可能)を理解する

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

FLASH19 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、利用者にインタラクションを完了させるための時間が終了することを通知することである。スクリプトで制限時間のある機能を提供している場合、スクリプトを用いて、利用者に制限時間が間もなく終了することを警告し、制限時間の延長を要求できるメカニズムを提供することが可能である。少なくとも制限時間の 20 秒前に、制限時間が間もなく終了することを通知して時間の延長が必要かどうかを利用者に確認する確認ダイアログをスクリプトにより提供する。利用者が「はい」と回答した場合は、制限時間をリセットする。利用者が「いいえ」と回答した場合、または応答がない場合は、制限時間の終了が認められる。

この実装方法では、setTimeout() メソッドで制限時間を設定する。例えば、制限時間を 60 秒にする場合、40 秒の制限時間を設定し (目的のタイムアウトよりも 20 秒前)、確認ダイアログを表示するという方法がある。この確認ダイアログで、残りの 20 秒間のタイムアウトを新たに設定する。利用者がより長い時間を必要としている場合は、新しいタイムアウトを設定する。ただし、20 秒間の「制限時間の猶予期間」が終了すると (つまり 60 秒が経過すると)、元々の設計で 60 秒の制限時間が終了するときに想定されている動作が実行される。

事例

事例 1: ActionScript を使用してタイムアウトに到達する前に制限時間の延長機能を提供する

これは、利用者により延長可能な制限時間の AS2 の基本例である。40 秒間操作しない場合は警告が表示され、セッションが間もなく終了すると警告される。利用者は、所定の 20 秒で、スペースキーを押すか、「はい」ボタンを押下する。40 秒という長さは、ほとんどのタスクで不十分であり、デモを簡単に行うために意図的に短くしていることに留意すること。

コード例:

import mx.controls.Alert;
import flash.accessibility.Accessibility;

mx.accessibility.AlertAccImpl.enableAccessibility();

var sessionTimeout;
var sessionNotificationTimeout;
var timeLimit: Number = 60000;
var sessionAlert: Alert;
resetTimeout();

testField.addEventListener("change", resetTimeout);

function resetTimeout() {
  clearTimeout(sessionTimeout);
  clearTimeout(sessionNotificationTimeout);
  sessionTimeout = setTimeout(endSession, timeLimit);
  sessionNotificationTimeout = setTimeout(showTimeoutAlert, timeLimit - 20000);
}

function showTimeoutAlert() {
  sessionAlert = Alert.show("Click the YES button to extend your session",
  "Your login session is about to expire, do you need more time?",
  Alert.YES | Alert.NO, null, handleAlertClick);
}

function endSession() {
  sessionAlert.deletePopUp();
  Alert.show("please log in again",
  "Your session has expired");
}

function handleAlertClick(e) {
  if (e && e.detail && e.detail == Alert.YES)
  resetTimeout();
}

この実例は、ActionScript を使用してタイムアウトに到達する前に制限時間の延長機能を提供するのサンプル (英語) で確認できる。また、ActionScript を使用してタイムアウトに到達する前に制限時間の延長機能を提供するのソース (英語) をダウンロードすることもできる。

SCR16: 制限時間が切れようとしていることを利用者に警告するスクリプトを提供する

検証

手順

ページをロードし、制限時間の 20 秒前まで待つ。
制限時間の 20 秒前になったとき、制限時間が間もなく終了することを警告する確認ダイアログが表示され、利用者が 20 秒以内に制限時間を延長できる。

期待される結果

2. を満たしている。

FLASH20: 非常に目立つフォーカス表示を提供するために Flash コンポーネントのスキンを切り替える

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.7 (フォーカスの可視化)
- クイックリファレンス 2.4.7 (フォーカスの可視化)
- 達成基準 2.4.7 (フォーカスの可視化)を理解する

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

FLASH20 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、コンテンツ制作者が ActionScript やコンポーネントのスキンを使用して、コンポーネントにフォーカスがあるときに視覚的な強調表示を行えるようにすることである。このテクニックでは、コンポーネントの背景色と境界線の両方を変更する。コンポーネントがフォーカスを失ったら、通常のスタイルに戻る。

視覚的な強調表示は、コンポーネントのスキンの一部を切り替えることによって行う。標準の Flash コンポーネントは、それぞれコンポーネントの外観を構成する独自のスキンのセットを持っている。各部分はムービークリップによって表現される。このムービークリップを編集するか、または置き換えることによって、コンポーネントの外観をカスタマイズすることができる。このテクニックに最も適したスキンは focusRectSkin スキンであり、これはすべてのコンポーネント間で共有される。このスキンのデフォルトでは、コンポーネントがフォーカスを受け取ると、わずかに視覚的な強調表示が行われる。

この実装方法は、次の手順で行うことができる。

focusRectSkin のカスタマイズバージョンを作成する。
スクリプトを使用して、カスタマイズしたスキンにコンポーネントを関連付ける。

スキンをカスタマイズするには次の二つの方法がある。

既存のスキンを複製する
この方法では、既存の focusRect スキンのコピーを作成して、それを変更する。このスキンは、コンポーネントの各インスタンスに手動で適用する必要がある (下記の手順 5)。
1. スタイルを適用するコンポーネントをステージにドラッグする。この操作により、スキンに関連付けられた適切なコンポーネントがムービーのライブラリに追加される。
2. 「ライブラリ」パネルを開き、Component Assets フォルダー > Shared フォルダーの順に移動する。
3. focusRectSkin ムービークリップを右クリック (Mac では Ctrl キーを押しながらクリック) し、コンテキストメニューから「複製」を選択する。
4. スキンのムービークリップの境界線の外観を編集する。例えば、より目立つようにフォーカス矩形の境界線を太くする (この手順は、以下のスクリーンショットで示されている)。
5. ActionScript を使用して、フォームコンポーネントのインスタンスを focusRectSkin のカスタマイズバージョンに関連付ける。これは、setStyle メソッドを使用して実現できる。
既存のスキンを変更する
この方法では、元の focusRect スキンを変更する。つまり、この変更はフォーカス可能なすべてのコンポーネントのフォーカス視覚表示に適用される。
1. スタイルを適用するコンポーネントをステージにドラッグする。この操作により、スキンに関連付けられた適切なコンポーネントがムービーのライブラリに追加される。
2. 「ライブラリ」パネルを開き、Component Assets フォルダー > Shared フォルダーの順に移動する。
3. focusRectSkin ムービークリップをダブルクリックして、編集用として開く。
4. スキンのムービークリップの境界線の外観を編集する。例えば、より目立つようにフォーカス矩形の境界線を太くする。
注記: この方法では、既存のスキンが上書きされることになる。上書きしたくない場合は、この方法ではなく「1. 既存のスキンを複製する」方法を用いること。

focusRect スキンは、フォーカス可能なすべての Flash コンポーネントに適用される。他の強調表示 (例えばコンポーネントの上にマウスを移動させた際に適用される強調表示など) を変更する場合は、各コンポーネントのスキンを個別に編集する必要がある。例えば、チェックボックスコンポーネントのマウスオーバーの強調表示を編集するには、 Checkbox_overIcon と Checkbox_selectedOverIcon の両方を変更するか、または複製する必要がある。同様に、ボタンコンポーネントのマウスオーバーの強調表示を編集するには、Button_over スキンを変更する必要がある。

また、特定のイベント (フォーカス、マウスオーバーなど) では、既存のスキンが自動的に適用されることを念頭に置く必要がある。ただし、開発者が選ぶタイミングでスキンを手動で切り替えることも可能である (例えば、テキストフィールドに無効なコンテンツが入力されていることを示す場合など)。これを行うには、setStyle メソッドを呼び出す。

事例

事例 1: フォーカスを太い青の境界線で表示する

次のコードは、フォームコンポーネントのインスタンスを、focusRectSkin ムービークリップの変更されたバージョンに関連付ける例を示している。この結果として、コンポーネントには Flash が提供するデフォルトの細い境界線ではなく、太い青の境界線が表示されるようになる。このコードは、Focus_custom という名前の変更されたスキンを参照しており、このスキンは事前にムービーのライブラリに追加されている。

focusRectSkin のこのカスタムバージョンでは、視覚的な強調表示をさらに高めるため、透過性のある黄色の背景も設定している。ボタンやチェックボックスなどのコンポーネントではこの背景が表示されるが、TextInput コンポーネントでは表示されない。TextInput のインスタンスにもこの黄色の背景が適用されるようにするには、次の手法を利用する。

TextInput の「normal」スキン (これはライブラリの「Component Asssets > TextInputSkins > TextInput_upSkin」にある) の複製バージョンを作成し、黄色の背景を表示するように編集する。
TextInput のインスタンスには FocusIn、FocusOut、MouseOver、MouseOut のハンドラが割り当てられており、これを利用して、コンポーネントにフォーカスがある間、またはコンポーネント上にマウスが置かれている間、デフォルトの「normal」スキンをカスタムの「normal」スキンに一時的に切り替えることができる。

また、button_over スキンを複製して変更することによって、ボタンコンポーネントインスタンスのデフォルトのマウスオーバーの強調表示を変更する。 checkbox_overIcon スキン、および checkbox_selectedOverIcon スキンは直接変更する。これにより、チェックボックスのすべてのインスタンスに対してこの変更が適用されることになる。

この実例は、フォーカスを太い青の境界線で表示するのサンプル (英語) で確認できる。

事例 1 のコード (ActionScript 3.0)

コード例:

package wcagSamples {
  import fl.accessibility.ButtonAccImpl;
  import fl.accessibility.CheckBoxAccImpl;
  import fl.controls.CheckBox;
  import fl.controls.Button;
  import fl.controls.Label;
  import fl.controls.TextInput;
  import flash.display.Sprite;
  import flash.events.FocusEvent;
  import flash.events.MouseEvent;
  
  public class FocusStyler extends Sprite {
    public function FocusStyler() {
      ButtonAccImpl.enableAccessibility()
      CheckBoxAccImpl.enableAccessibility()
      
      var lbl1: Label = new Label();
      lbl1.text = "name";
      lbl1.x = lbl1.y = 20;
      addChild(lbl1);
      
      var txt1: TextInput = new TextInput();
      txt1.x = 60;
      txt1.y = 20;
      txt1.width = 200;
      txt1.addEventListener(FocusEvent.FOCUS_IN, handleFocusIn);
      txt1.addEventListener(FocusEvent.FOCUS_OUT, handleFocusOut);
      txt1.addEventListener(MouseEvent.MOUSE_OVER, handleFocusIn);
      txt1.addEventListener(MouseEvent.MOUSE_OUT, handleFocusOut);
      txt1.setStyle("focusRectSkin", "focus_custom");
      addChild(txt1);
      
      var chk1: CheckBox = new CheckBox();
      chk1.label = "Check Me";
      chk1.x = 60;
      chk1.y = 70;
      chk1.setStyle("focusRectSkin", "focus_custom");
      addChild(chk1);
      
      var btn1: Button = new Button();
      btn1.label = "Click Me";
      btn1.x = 60;
      btn1.y = 110;
      btn1.setStyle("focusRectSkin", "focus_custom");
      btn1.setStyle("overSkin", "Button_over_custom");
      addChild(btn1);
    }
    
    private function handleFocusIn(event) {
      event.currentTarget.setStyle("upSkin", "TextInput_upSkin_custom");
    }
    
    private function handleFocusOut(event) {
      event.currentTarget.setStyle("upSkin", "TextInput_upSkin");
    }
  }
}

この実例は、フォーカスを太い青の境界線で表示するのサンプル (英語) で確認できる。また、フォーカスを太い青の境界線で表示するのソース (英語) をダウンロードすることもできる。

参考リソース

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

Creating ActionScript 3.0 components in Flash – Part 5: Styles and skins

SCR31: フォーカスのある要素の背景色又はボーダーを変更するために、スクリプトを使用する

検証

手順

Flash ムービーにフォーカス可能なコンポーネントが含まれている場合は、次のことを確認する。

視覚的な強調表示が、コンポーネントのスキンを変更することによって適用されている。
コンポーネントがフォーカスを受け取ると、視覚的な強調された表示になる。

期待される結果

1. および 2. を満たしている。

FLASH21: 列見出しとデータセルを関連付けるために、DataGrid コンポーネントを使用する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

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

FLASH21 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、データテーブルで視覚的に示されている情報とそれらの関連性を、プログラムが解釈できるようにすることである。具体的には、テーブルの列見出しとそれに対応するデータセルの関連性を支援技術が解釈できるようにする必要がある。Flash では、この実現方法として DataGrid コンポーネントを使用できる。DataGrid コンポーネントでアクセシビリティを有効にした場合、Flash はグリッドの行のアクセシブルな名前を支援技術に渡す際に、各セルの値の前に自動的に列名を付加する。例えば、次のスクリーンショットの行は、スクリーンリーダーによって「13 行中の 6 行目 Name Patty Crawford Bats L Throws L Year Jr Home Whittier, CA」と読み上げられる。

注記: Flash の DataGrid コンポーネントは列見出しのみをサポートし、行見出しはサポートしていない。

画面スクリーンショット: 6行目が強調表示されたDataGrid コンポーネント

事例

事例 1: 統計データのテーブル

この事例では、DataGrid コンポーネントを動的に作成し、そのデータプロバイダとして静的なデータが使用されている。import fl.accessibility.DataGridAccImpl; DataGridAccImpl.enableAccessibility(); は、Datagrid コンポーネントのアクセシビリティを有効にするために必要な行である。

コード例:

import fl.accessibility.DataGridAccImpl;
DataGridAccImpl.enableAccessibility();

import fl.data.DataProvider;
bldRosterGrid(aDg);
var aRoster: Array = new Array();
aRoster = [ {
  Name: "Wilma Carter", Bats: "R", Throws: "R", Year: "So", Home: "Redlands, CA"}, {
  Name: "Sue Pennypacker", Bats: "L", Throws: "R", Year: "Fr", Home: "Athens, GA"}, {
  Name: "Jill Smithfield", Bats: "R", Throws: "L", Year: "Sr", Home: "Spokane, WA"}, {
  Name: "Shirley Goth", Bats: "R", Throws: "R", Year: "Sr", Home: "Carson, NV"}, {
  Name: "Jennifer Dunbar", Bats: "R", Throws: "R", Year: "Fr", Home: "Seaside, CA"}, {
  Name: "Patty Crawford", Bats: "L", Throws: "L", Year: "Jr", Home: "Whittier, CA"}, {
  Name: "Angelina Davis", Bats: "R", Throws: "R", Year: "So", Home: "Odessa, TX"}, {
  Name: "Maria Santiago", Bats: "L", Throws: "L", Year: "Sr", Home: "Tacoma, WA"}, {
  Name: "Debbie Ferguson", Bats: "R", Throws: "R", Year: "Jr", Home: "Bend, OR"}, {
  Name: "Karen Bronson", Bats: "R", Throws: "R", Year: "Sr", Home: "Billings, MO"}, {
  Name: "Sylvia Munson", Bats: "R", Throws: "R", Year: "Jr", Home: "Pasadena, CA"}, {
  Name: "Carla Gomez", Bats: "R", Throws: "L", Year: "Sr", Home: "Corona, CA"}, {
  Name: "Betty Kay", Bats: "R", Throws: "R", Year: "Fr", Home: "Palo Alto, CA"}
];
aDg.dataProvider = new DataProvider(aRoster);
aDg.rowCount = aDg.length;

function bldRosterGrid(dg: DataGrid) {
  dg.setSize(400, 300);
  dg.columns =[ "Name", "Bats", "Throws", "Year", "Home"];
  dg.columns[0].width = 120;
  dg.columns[1].width = 50;
  dg.columns[2].width = 50;
  dg.columns[3].width = 40;
  dg.columns[4].width = 120;
  dg.move(50, 50);
};

この実例は、統計データのテーブルのサンプル (英語) で確認できる。また、統計データのテーブルのソース (英語) をダウンロードすることもできる。

検証

手順

テーブル形式のデータを含む Flash コンテンツで以下を実行する。

Internet Explorer 6 以降 (Flash Player 6 以降を使用)、または Firefox 3 以降 (Flash Player 9 以降を使用) で SWF ファイルを開く。
オブジェクトのアクセシビリティ名を表示できる ACTFa Designer 1.0 などのツールを使用して Flash ムービーを開く。
GUI 概要パネルでデータグリッドの行とセルのアクセシビリティ名を調べて、見出しデータとデータセルのデータがともに存在する。
コンテンツ制作者は、テストにスクリーンリーダーを使用することもできる。その場合は、Flash コンテンツを読み上げて音声を聞き、データグリッドが読み上げられる際に見出しとデータセルのデータが読み上げられる。
または、Flash オーサリングツールで、DataGrid コンポーネントを使用してデータが構造化されており、DataGridAccImpl.enableAccessibility メソッドによって DataGrid がアクセシブルになっている。

期待される結果

3., 4. 又は 5. を満たしている。

FLASH22: キーボードアクセシブルな操作を静的エレメントに追加する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 2.1.1 (キーボード)
- クイックリファレンス 2.1.1 (キーボード)
- 達成基準 2.1.1 (キーボード)を理解する
注記: この達成方法は、達成基準 2.1.1 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 2.1.1 を理解するを参照すること。
達成基準 2.1.3 (キーボード (例外なし) )
- クイックリファレンス 2.1.3 (キーボード (例外なし) )
- 達成基準 2.1.3 (キーボード (例外なし) )を理解する
注記: この達成方法は、達成基準 2.1.3 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 2.1.3 を理解するを参照すること。

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

FLASH22 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、デフォルトではキーボードで操作できない Flash ムービークリップをキーボードで操作可能にする方法を示すことである。この実装方法では、tabEnabled プロパティを設定してエレメントをフォーカス可能にし、click ハンドラに加えて keydown ハンドラを提供してキーボードからアクションをトリガできるようにする。

事例

事例 1: ムービークリップをボタンとして使用する

この事例では、カスタムムービークリップをボタンとして使用する。キーボードでの操作を可能にするため、tabEnabled を使用してムービークリップをタブの順序に配置する。さらに、カスタムボタンがマウスクリックとスペースキーの打鍵の両方に反応するように、冗長なイベントハンドラを追加する。最後に、ムービークリップの AccessibilityProperties オブジェクトを使用して、カスタムボタンにアクセシブルな名前を付ける。これにより、支援技術でボタンのラベルを認識できるようになる。

この実例は、ムービークリップをボタンとして使用するのサンプル (英語) で確認できる。ムービークリップをボタンとして使用するのソース (英語) をダウンロードすることもできる。

注記: カスタムボタンはボタンではなくフォーカス可能なグラフィックとして認識されるので、汎用のムービークリップを使用することは一般的に推奨されない。代わりに、標準の Flash の Button コンポーネントを使用するか、「button」タイプの新規シンボルを作成することが望ましい。

コード例:

import flash.accessibility. *
import flash.events.KeyboardEvent;
import flash.events.MouseEvent;
import flash.net.navigateToURL;
import flash.net.URLRequest;

testMC.tabEnabled = true;
updateAccName(testMC);
testMC.addEventListener(MouseEvent.CLICK, clickHandler, false);
testMC.addEventListener(KeyboardEvent.KEY_DOWN, keyDownHandler);

updateAccName(testMC);

function clickHandler(e) {
  testMC.labelText.text = "THANKS";
  updateAccName(testMC);
}

function keyDownHandler(e) {
  if (e.keyCode == 32)
  clickHandler(e);
}

function updateAccName(mc: MovieClip) {
  if (! mc.accessibilityProperties)
  mc.accessibilityProperties = new AccessibilityProperties();
  mc.accessibilityProperties.name = mc.labelText.text;
  Accessibility.updateProperties();
}

検証

手順

インタラクティブコントロールとして使用されるムービークリップの汎用インスタンスが Flash ムービーに含まれている場合は、次のことを確認する。

ムービークリップインスタンスの tabEnabled プロパティが true に設定されている。
ムービークリップインスタンスにマウスとキーボードの両方のイベントに対応するイベントハンドラがある。

期待される結果

1. および 2. を満たしている。

FLASH23: DataGrid に要約を追加する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

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

FLASH23 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、データグリッド内でデータがどのように提示されているかについて要約を提供したり、グリッド内での移動方法について簡単に説明したりすることである。

Flash は summary 属性を提供しないので、代わりにこの説明的なテキストがデータグリッドのアクセシブルな説明に追加される。このアプローチでは、スクリーンリーダーを使用する利用者が要約の情報を利用できるようになる。情報は視覚的に表示されない。

要約は、テーブルの構造が複雑な場合 (例えば、行見出しまたは列見出しのセットが複数ある場合や、列または行のグループが複数ある場合) に役立つ。また、要約は、多くのデータ列またはデータ行を含む単純なデータテーブルでも役に立つ場合がある。

事例

事例 1: アクセシビリティパネルを使用してデータグリッドに一覧を追加する

ここでは、Flash Professional でコンポーネントパネルからステージに追加されるデータグリッドの例を示す。データグリッドの要約を提供するために、Flash のアクセシビリティパネルの「説明」フィールドを使用する。

新しい Flash ファイル (.fla) を作成する、又は既存のファイルを開いてデータグリッドを挿入する。
ウィンドウメニューから Flash のコンポーネントパネルを開く。
データグリッドコンポーネントをステージ上にドラッグし、目的の位置に配置する。
データグリッドコンポーネントを選択し、アクセシビリティパネルを使用して、データグリッドの要約を「説明」フィールドに追加する。

事例 2: ActionScript 3 を使用してデータグリッドに一覧を追加する

This is a basic AS3 example of a DataGrid component that has summary text added as its accessible description.

コード例:

import fl.accessibility.DataGridAccImpl;
import fl.controls.DataGrid;
import fl.controls.Label;
import fl.data.DataProvider;
import flash.accessibility.Accessibility;
import flash.accessibility.AccessibilityProperties;
import flash.system.Capabilities;

DataGridAccImpl.enableAccessibility();

createGrid();

//要約テキストをアクセシブルな「説明」として設定する
var accProps: AccessibilityProperties = new AccessibilityProperties();
accProps.description = "The first column shows the player's name," +
  "the second and third column shows the player's gaming statistics." +
  "the fourth column shows the player's year as FR (Freshman), JR (junior) or SO (Sophomore)." +
  "The fifth column shows the player's home city and state";
aDg.accessibilityProperties = accProps;
if (Capabilities.hasAccessibility)
Accessibility.updateProperties();

function createGrid() {
  
  //コンポーネントを作成して追加する
  var aDg: DataGrid = new DataGrid();
  addChild(aDg);
  aDg.move(50, 50);
  bldRosterGrid(aDg);
  
  var aRoster: Array = new Array();
  aRoster =[ {
    Name: "Wilma Carter", Bats: "R", Throws: "R", Year: "So", Home: "Redlands, CA"
  }, {
    Name: "Sue Pennypacker", Bats: "L", Throws: "R", Year: "Fr", Home: "Athens, GA"
  }, {
    Name: "Jill Smithfield", Bats: "R", Throws: "L", Year: "Sr", Home: "Spokane, WA"
  }, {
    Name: "Betty Kay", Bats: "R", Throws: "R", Year: "Fr", Home: "Palo Alto, CA"
  },];
  aDg.dataProvider = new DataProvider(aRoster);
  aDg.rowCount = aDg.length;
}

function bldRosterGrid(dg: DataGrid) {
  dg.setSize(400, 300);
  dg.columns =[ "Name", "Bats", "Throws", "Year", "Home"];
  dg.columns[0].width = 120;
  dg.columns[1].width = 50;
  dg.columns[2].width = 50;
  dg.columns[3].width = 40;
  dg.columns[4].width = 120;
};

この実例は、ActionScript 3 を使用してデータグリッドに一覧を追加するのサンプル (英語) で確認できる。また、ActionScript 3 を使用してデータグリッドに一覧を追加するのソース (英語) をダウンロードすることもできる。

検証

手順

Flash ムービーにデータグリッドコンポーネントが含まれている場合、対応するアクセシブルな説明プロパティを使用して、要約テキストが追加されている。

期待される結果

上記手順を満たしている。

FLASH24: 利用者がデフォルトの制限時間を延長できるようにする

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.1 (タイミング調整可能)
- クイックリファレンス 2.2.1 (タイミング調整可能)
- 達成基準 2.2.1 (タイミング調整可能)を理解する

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

FLASH24 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、スクリプトでデフォルトの制限時間が設定されている場合に、制限時間を延長するメカニズムを提供して、利用者がデフォルトの制限時間を延長できるようにすることである。利用者が制限時間の延長を要求できるように、利用者が長い制限時間を入力したり長い時間が必要なことを指定したりできるフォームなどをスクリプトで提供することができる。

事例

事例 1: ドロップダウンリストを使用してタイムアウトを変更する

ここでは、利用者がドロップダウンリストを使用してタイムアウト時間を変更できる、基本的な AS2 の例を示す。この例には、sessionLimitDuration というインスタンス名のコンボボックスがある。

コード例:

import mx.controls.Alert;
import mx.accessibility.AlertAccImpl;
import mx.accessibility.ComboBoxAccImpl;

ComboBoxAccImpl.enableAccessibility();
AlertAccImpl.enableAccessibility();

var sessionTimeout;
var sessionNotificationTimeout;
var timeLimit: Number;
var sessionAlert: Alert;

adjustTimeoutDuration();
// インタラクションが発生したらタイムアウトをリセットする
testField.addEventListener("change", resetTimeout);

//
//combobox の値が変更されたら制限時間を更新する
//
sessionLimitDuration.addEventListener("change", adjustTimeoutDuration);

function adjustTimeoutDuration(e) {
  timeLimit = sessionLimitDuration.value * 1000;
  resetTimeout();
  timeoutDescription.text = "A session timeout will be simulated after " + 
    sessionLimitDuration.selectedLabel + " without interaction in the form field below."
}

function resetTimeout() {
  clearTimeout(sessionTimeout);
  sessionTimeout = setTimeout(endSession, timeLimit);
}

function endSession() {
  sessionAlert.deletePopUp();
  Alert.show("please log in again",
  "Your session has expired");
}

この実例は、ドロップダウンリストを使用してタイムアウトを変更するのサンプル (英語) で確認できる。また、ドロップダウンリストを使用してタイムアウトを変更するのソース (英語) をダウンロードすることもできる。なお、このサンプルではデモンストレーションが目的であるため、セッション時間を意図的に短くしてある。コンテンツ制作者は、「達成基準 2.2.1 (調整可能な制限時間)」の要件を満たすための十分な時間を提供する必要がある。

検証

手順

制限時間を含む Flash コンテンツで次のことを確認する。

ページの先頭に制限時間を調整するためのコントロールがあり、利用者がデフォルトの 10 倍以上の時間に調整できる
ページのデフォルトの制限時間が、普通の 10 倍の時間が必要な利用者でも 1. のコントロールに簡単に移動できる長さである

期待される結果

1. および 2. を満たしている。

FLASH25: アクセシブルな名前 (accessible name) を設定することによって、フォームコントロールにラベルを付ける

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

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

FLASH25 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、Flash で提供されるフォームコンポーネントに組み込むアクセシブルな名前を設定することである。ラジオボタン、チェックボックス、ボタンなど、コンポーネントによっては自身に固有な label プロパティが既に与えられているが、その他のコンポーネントについては、コンテンツ制作者がコンポーネントのアクセシブルな名前となるラベルテキストを指定する必要がある。そのためには、アクセシビリティパネルを使用するか (オーサリング中にステージ上にコンポーネントを配置する場合)、スクリプトを使用する (実行時に動的にコンポーネントを生成する場合)。

ActionScript 2

ActionScript 2 では、コンポーネントの _accProps プロパティにアクセシブルな名前を設定する必要がある。このプロパティはオブジェクトでなければならない。プロパティがまだ設定されていない場合は、コンテンツ制作者がカスタムオブジェクトを作成して _accProps プロパティに割り当てる必要がある。場合によっては、一つのオブジェクトに対し、アクセシブルな名前を指定する _accProps.name を含む複数のアクセシビリティ関連プロパティがある。_accProps プロパティを変更した場合、コンテンツ制作者は、Accessibility.UpdateProperties() を呼び出してその変更を有効にする必要がある。MSAA に対応していない環境でエラーが発生するのを防ぐため、Accessibility.UpdateProperties() を呼び出す前に System.capabilities.hasAccessibility フラグを確認することを推奨する。

ActionScript 2 には、以下のアクセシブルなコンポーネントが用意されている。

SimpleButton
CheckBox
RadioButton
Label
TextInput
TextArea
ComboBox
ListBox
Window
Alert
DataGrid

ActionScript 3

ActionScript 3 では、コンポーネントの accessibilityProperties プロパティにアクセシブルな名前を設定する必要がある。このプロパティは flash.accessibility.AccessibilityProperties のインスタンスでなければならない。プロパティがまだ設定されていない場合は、コンテンツ制作者が新しい AccessibilityProperties インスタンスを作成して accessibilityProperties プロパティに割り当てる必要がある。場合によっては、一つのオブジェクトに対し、アクセシブルな名前を指定する accessibilityProperties.name を含む複数のアクセシビリティ関連プロパティがある。accessibilityProperties プロパティを変更した場合、コンテンツ制作者は、flash.accessibility.Accessibility.UpdateProperties()を呼び出してその変更を有効にする必要がある。MSAA に対応していない環境でエラーが発生するのを防ぐため、Accessibility.UpdateProperties() を呼び出す前に flash.system.capabilities.hasAccessibility フラグを確認することを推奨する。

ActionScript 3 には、以下のアクセシブルなコンポーネントが用意されている。

Button
CheckBox
ComboBox
List
RadioButton
TileList

事例

事例 1: アクセシビリティパネルを使用してコンポーネントのアクセシブルな名前を設定する

コンポーネントコントロールを追加してラベルを付ける手順は次の通りである。

コンポーネントパネルからコンポーネントをステージへドラッグするか、スクリプトを使用して新しいインスタンスを作成する。
新しく作成したコンポーネントインスタンスを選択した状態で、対応するラベルテキストをアクセシビリティパネルの「名前」フィールドに入力する。

事例 2: ActionScript 2.0 を使用してアクセシブルな名前を設定する

次のコード例は、ListBox コンポーネントを作成してアクセシブルな名前を割り当てる方法を示している。

コード例:

mx.accessibility.ListAccImpl.enableAccessibility();

this.createClassObject(mx.controls.List, "my_list", 1);
my_list.addItem({label: "R. Davis", data: 1});
my_list.addItem({label: "V. Mann", data: 2});
my_list.addItem({label: "L. Heart", data: 3});
my_list.addItem({label: "P. Hill", data: dt4});
my_list.addItem({label: "D. Gribble", data: 5});
my_list.move(10, 10);

if (System.capabilities.hasAccessibility) {
  my_list._accProps = new Object();
  my_list._accProps.name = "Staff Members";
  Accessibility.updateProperties();
}

この実例は、ActionScript 2.0 を使用してアクセシブルな名前を設定するのサンプル (英語) で確認できる。また、ActionScript 2.0 を使用してアクセシブルな名前を設定するのソース (英語) をダウンロードすることもできる。

事例 3: ActionScript 3.0 を使用してアクセシブルな名前を設定する

次のコード例は、ListBox コンポーネントを作成してアクセシブルな名前を割り当てる方法を示している。

コード例:

import fl.controls.List;
import fl.accessibility.ListAccImpl;
import flash.system.Capabilities;
import flash.accessibility.*;

ListAccImpl.enableAccessibility();
var my_list:List = new List();
my_list.addItem({label:"R. Davis", data:1});
my_list.addItem({label:"V. Mann", data:2});
my_list.addItem({label:"L. Heart", data:3});
my_list.addItem({label:"P. Hill", data:4});
my_list.addItem({label:"D. Gribble", data:5});
my_list.x = my_list.y = 10;

if (Capabilities.hasAccessibility) {
  var accProps:AccessibilityProperties = new AccessibilityProperties();
  accProps.name = "Staff Members";
  my_list.accessibilityProperties = accProps;
  Accessibility.updateProperties();
}
addChild(my_list);

この実例は、ActionScript 3.0 を使用してアクセシブルな名前を設定するのサンプル (英語) で確認できる。また、ActionScript 3.0 を使用してアクセシブルな名前を設定するのソース (英語) をダウンロードすることもできる。

G94: 非テキストコンテンツに対して、それと同じ目的を果たし、かつ同じ情報を示す、簡潔なテキストによる代替を提供する

検証

手順

フォームコンポーネントを含む Flash ムービーについて、以下のいずれかを満たしているか確認する。

選択されているコンポーネントのラベルテキストがアクセシビリティパネルの「名前」フィールドで指定されている。
(ActionScript 2.0 の場合) スクリプトを使用してコンポーネントの _accProps.name プロパティが動的に設定されている。
(ActionScript 3.0 の場合) スクリプトを使用してコンポーネントの accessibilityProperties.name プロパティが動的に設定されている。

期待される結果

上記のどれか一つを満たしている。

FLASH26: Flash ビデオに音声解説をつける

適用 (対象)

Flash CS3 以上
ActionScript 3.0 以上

これは、次の達成基準に関連する達成方法である:

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

FLASH26 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、全盲の利用者または視聴覚素材の映像を見ることが困難な利用者がコンテンツの内容を理解できるようにする方法を提供することである。この実装方法では、視聴覚素材の会話の合間に、映像だけで伝えられている情報を説明する音声解説を挿入する。

事例

事例 1: キューポイントに到達したときに解説を再生する

この事例では、FLVPlayback コンポーネントを使用してビデオプレーヤーを作成する。AudioDescriptions という名前のカスタムクラスを追加して、拡張音声解説の再生を管理する。このクラスは、メディア内で音声解説のプロバイダによって識別されるキューポイントをリッスンするイベントリスナーを提供する。これらのキューポイントに到達すると、対応する解説を含む mp3 ファイルの再生が開始される。録音された解説はムービーの会話の合間に収まる時間に設定されている。

音声解説はデフォルトで有効になる。ビデオプレーヤーの下に用意されているボタンによって、利用者は音声解説をオンまたはオフにできる (このボタンは他の達成基準を満たすためにアクセシブルである必要がある)。

コード例:

package {
  import fl.video. *;
  import flash.events. *;
  import flash.media.Sound;
  import flash.media.SoundChannel;
  import flash.net.URLRequest;
  import flash.display.Sprite;
  
  public class AudioDescriptions extends Sprite {
    private var channel: SoundChannel = new SoundChannel;
    private var myPlayer: FLVPlayback;
    private var _enabled: Boolean = true;
    private var _toggleBtn: Button;
    private var snd: Sound = new Sound();
    public function AudioDescriptions() {
      // point myPlayer to the FLVPlayback component instance on the stage, 
      // which should be loaded with a valid video source.
      myPlayer = my_FLVPlybk;
      // add cue points. When any of these are reached, the 
      // MetadataEvent.CUE_POINT event will fire
      myPlayer.addASCuePoint(8.35, "ASpt1");
      myPlayer.addASCuePoint(23.23, "ASpt2");
      
      enable();
      
      enable_AD_btn.addEventListener(MouseEvent.CLICK, handleBtnClick);
    }
    
    private function handleBtnClick(e) {
      _enabled = ! _enabled;
      if (! _enabled) {
        disable();
        enable_AD_btn.label = "Enable Audio Descriptions";
      } else {
        enable();
        enable_AD_btn.label = "Disable Audio Descriptions";
      }
    }
    
    public function enable() {
      // set up an event handler which will be called each time a cue point is reached
      myPlayer.addEventListener(MetadataEvent.CUE_POINT, cp_listener);
    }
    
    public function disable() {
      // remove the event handler called each time a cue point is reached, so 
      // that audio description is disabled.
      myPlayer.removeEventListener(MetadataEvent.CUE_POINT, cp_listener);
    }
    
    private function cp_listener(eventObject: MetadataEvent): void {
      snd = new Sound();
      //recreate sound object as it can only load one mp3 file
      //check to see which cue point was reached
      switch (eventObject.info.name) {
        case "ASpt1":
        snd.load(new URLRequest("sphere.mp3"));
        //create a new Sound object, and load the appropriate mp3
        channel = snd.play();
        // play the audio description, and assign it to the SoundChannel object
        break;
        case "ASpt2":
        snd.load(new URLRequest("transfrm.mp3"));
        channel = snd.play();
        break;
      }
    }
  }
}

この実例は、キューポイントに到達したときに解説を再生するのサンプル (英語) で確認できる。また、キューポイントに到達したときに解説を再生するのソース (英語) をダウンロードすることもできる。

事例 2: 解説のための追加の音声トラックを提供する

音声解説は、追加の音声トラックを通して提供することもできる。この場合、追加の音声トラックはメインのメディアと同じ長さにし、同期して再生させる。ただし、音声解説の再生が必要な箇所のみに音声を含め、他の部分は無音にする。Flash 制作者は、リスナーの好みに応じてこの追加の音声トラックのオン/オフを切り替えるための機能を提供することができる。追加のトラックが有効になっている場合は、二つの音声トラック (一つはメイン音声、もう一つは音声解説のみが含まれているトラック) が並行して再生される。音声解説とメイン音声は、音声が重なって聞き取りが困難になることのないようにする必要がある。この手法は、事例 1 で使用されている手法と同じ効果が期待できる。ただし、Flash 制作者に提供される音声解説ファイルの種類によっては、こちらの手法を選択したほうがいい場合もある。

検証

手順

Flash コンテンツに音声サウンドトラック付きの映像が含まれている場合は、次のことを確認する。

別の音声ファイルを使用した音声解説が利用可能である
利用者が音声解説を有効または無効にするためのボタンが用意されている

期待される結果

1. および 2. を満たしている。

FLASH27: ボタンの目的を説明するラベルを提供する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

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

FLASH27 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、ボタンのアクセシブルな名前として説明的なテキストを提供して、ボタンの目的を記述することである。この説明により、利用者はこのボタンとその他の Flash ムービーのボタンを区別でき、このボタンを有効化するかどうかを決定できる。ボタンのアクセシブルな名前として、空の文字列では不十分である。

テキストラベル付きのボタンの場合、ラベルテキストがボタンのアクセシブルな名前として使用される。画像ベースのボタンでテキストラベルが付いていない場合、このボタンのアクセシブルな名前は、アクセシビリティパネルを使用するか、またはスクリプトによって、別途設定する必要がある。

事例

事例 1: ラベルプロパティを使用してボタンの目的を記述する

コード例:

import fl.controls.Button;
import fl.accessibility.ButtonAccImpl;

ButtonAccImpl.enableAccessibility();

var myButton:Button = new Button();
myButton.label = "View Items in Cart";

事例 2: スクリプトを使用して、ActionScript 3.0 により画像ボタンのアクセシブルな名前を設定する

この事例では、ボタンの label プロパティで意図的に空の文字列を設定する。支援技術で認識できるようにするには、ボタンの accessibilityProperties.name プロパティを設定する。

コード例:

import fl.controls.Button;
import fl.accessibility.ButtonAccImpl;
import flash.accessibility.*;
import flash.system.Capabilities;
ButtonAccImpl.enableAccessibility();

var soundIsMuted = false;
var myButton:Button = new Button();
myButton.setStyle("icon", unmuted);
myButton.label = "";
myButton.x = myButton.y = 10;
myButton.width = myButton.height = 50;
updateAccName(myButton, "mute sound");
myButton.setStyle("icon", unmuted);
myButton.addEventListener(MouseEvent.CLICK, handleBtnClick);
addChild(myButton);

function handleBtnClick(e) {
  soundIsMuted = !soundIsMuted;
  myButton.setStyle("icon", soundIsMuted ? muted : unmuted);
  updateAccName(myButton, soundIsMuted ? "unmute sound" : "mute sound");
}

function updateAccName(obj, newName:String) {
  if (!obj.accessibilityProperties)
    obj.accessibilityProperties = new AccessibilityProperties();
  obj.accessibilityProperties.name = newName;
  if (Capabilities.hasAccessibility)
    Accessibility.updateProperties();
}

検証

手順

この実装方法を用いている Flash ムービーの各ボタンについて、次のことを確認する。

ボタンのラベルテキストがボタンの目的を正しく説明している
ボタンにテキストラベルがない場合、ボタンのアクセシブルな名前として説明的なテキストが追加されている
ボタンにラベルテキストとアクセシブルな名前の両方が含まれている場合、その二つの組み合わせが、ボタンの目的の説明として正しいものである

期待される結果

1., 2. 及び 3. を満たしている。

FLASH28: Flash で ASCII アート、顔文字、リート語に対するテキストによる代替を提供する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

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

FLASH28 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

ASCII 文字、顔文字、リート語 (当て字) が使用されると、アクセシビリティ上の問題が発生することがある。その理由は、文字のグループの見た目によって意味を伝えているからである。

Flash では、このような文字のグループをムービークリップにラップし、アクセシブルな名前を提供することによってアクセシブルにすることが出来る。ムービークリップの forceSimple プロパティに true を設定することも重要である。この設定により、実際の ASCII 文字が支援技術から隠される。

事例

事例 1: アクセシビリティパネルを使用して ASCII アートのテキストによる代替を提供する

この事例には、当て字を使用した ASCII アートによる語が含まれている (テキストは「WCAG 2 rulez」を表している)。次の手順で、このテキストのアクセシビリティを確保する。

ムービークリップインスタンスに ASCII 文字を配置する。
テキストが配置されたムービークリップインスタンスを選択し、アクセシビリティパネルで次の変更を行う。
- ASCII アートに対して、当て字を使用していない意味のあるテキストによる代替を追加する (「WCAG 2 RULEZ」など)。
- 「子オブジェクトをアクセス可能にする」チェックボックスをオフにし、ASCII 文字がスクリーンリーダーによって読み上げられないようにする。

上記の手順を次のスクリーンショットで示す。

画面スクリーンショット: アクセシビリティパネルを用いて、ASCIIアートのテキストによる代替を提供

事例 2: ActionScript を使用して ASCII アートのテキストによる代替を提供する

この事例では、Flash Professional のオーサリングツールのアクセシビリティパネルの代わりに ActionScript を使用している。それ以外は事例 1 と同じである。

ムービークリップインスタンスに ASCII 文字を配置する。
ムービークリップインスタンスのインスタンス名 (myASCII など) を指定する。
ムービークリップにアクセシブルな名前を設定し、ムービークリップ内部のテキストをアクセス不可にするために forceSimple プロパティを true に設定する。

コード例:

// 'myASCII' はムービーのメインのタイムライン上に置かれたムービークリップインスタンスである
myASCII.accessibilityProperties = new AccessibilityProperties();
myASCII.accessibilityProperties.name = "WCAG 2 Rulez";
myASCII.accessibilityProperties.forceSimple = true;

この実例は、ActionScript を使用して ASCII アートのテキストによる代替を提供するのサンプル (英語) で確認できる。また、ActionScript を使用して ASCII アートのテキストによる代替を提供するのソース (英語) をダウンロードすることもできる。

検証

手順

SWF ファイルを発行する。
オブジェクトの名前を表示できるツールを使用して Flash ムービーを開く。
グループ化された ASCII 文字、当て字、顔文字に、同じ情報がアクセシビリティの name プロパティによって提供されている。
また、場合によってはスクリーンリーダーを使用して Flash コンテンツの読み上げをテストする。このテストでは、タブ移動の可能な非テキストオブジェクトにタブ移動したときにそのオブジェクトの等価なテキストが読み上げられる。または、コンテンツを 1 行ずつ読み上げたときに代替テキストが読み上げられる。

期待される結果

3. または 4. を満たしている。

FLASH29: フォームコンポーネントに label プロパティを設定する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

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

FLASH29 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この達成方法の目的は、フォームコンポーネントに label プロパティを設定することによって、フォームコンポーネントにラベルテキストを明示的に関連付けることである。このプロパティを設定することにより、コンポーネントの隣にラベルが視覚的に配置されるようになり、支援技術に対してラベルテキストが提示されるようになる。

label プロパティをサポートするコンポーネントは以下のとおりである。

その他のコンポーネントについては、手動でフォームコンポーネントの隣にラベルテキストを配置する必要がある。これらのコンポーネントについては、以下のいずれかのアプローチを用いて、フォームコンポーネントにラベルテキストを関連付けることができる。

FLASH25: アクセシブルな名前 (accessible name) を設定することによって、フォームコントロールにラベルを付ける
FLASH32: フォームコントロールにテキストラベルを関連付けるために、自動ラベリングを使用する

事例

支援技術からこれらのフォームコントロールにアクセスできるようにするには、以下のコード行をムービーのスクリプトに一度追加する必要がある。

Button コンポーネントを使用する場合:

import fl.accessibility.ButtonAccImpl; ButtonAccImpl.enableAccessibility();

RadioButton コンポーネントを使用する場合:

import fl.accessibility.RadioButtonAccImpl; RadioButtonAccImpl.enableAccessibility();

CheckBox コンポーネントを使用する場合:

import fl.accessibility.CheckBoxAccImpl; CheckBoxAccImpl.enableAccessibility();

事例 1: コンポーネントインスペクタパネルを使用してラベルを設定する

コンポーネントパネルから Button、CheckBox、RadioButton のいずれかのコンポーネントをステージにドラッグしてムービーに追加する。
コンポーネントを選択した状態で、「ウィンドウ」メニューまたは Shift + F7 ショートカットを使用して、コンポーネントインスペクタパネルを開く。
コンポーネントインスペクタの「パラメータ」タブで、「label」パラメータにラベルテキストを入力する。

下のスクリーンショットはこの実装方法を示している。

画面スクリーンショット: コンポーネントインスペクタパネルで、コンポーネントのラベルを設定

事例 2: ActionScript 3.0 を使用して、Button、CheckBox、RadioButton の各コンポーネントのラベルを設定する

コード例:

import fl.accessibility.ButtonAccImpl
import fl.accessibility.CheckBoxAccImpl
import fl.accessibility.RadioButtonAccImpl
import fl.controls.Button;
import fl.controls.CheckBox;
import fl.controls.RadioButton;

ButtonAccImpl.enableAccessibility();
var myButton: Button = new Button();
myButton.label = "Submit Details";
myButton.x = 10;
myButton.y = 10
addChild(myButton);

CheckBoxAccImpl.enableAccessibility();
var myCheckBox: CheckBox = new CheckBox();
myCheckBox.label = "notify me";
myCheckBox.x = 10;
myCheckBox.y = 40
addChild(myCheckBox);

RadioButtonAccImpl.enableAccessibility();
var myRadioButton: RadioButton = new RadioButton();
myRadioButton.label = "Male";
myRadioButton.x = 10;
myRadioButton.y = 60;
addChild(myRadioButton);

この実例は、ActionScript 3.0 を使用して、Button、CheckBox、RadioButton の各コンポーネントのラベルを設定するのサンプル (英語) で確認できる。また、ActionScript 3.0 を使用して、Button、CheckBox、RadioButton の各コンポーネントのラベルを設定するのソース (英語) をダウンロードすることもできる。

検証

手順

Button、CheckBox、RadioButton の各コンポーネントを使用している場合、次のことを確認する。

コンポーネントの label プロパティによって、ボタンの目的を説明したラベルが提供されている

期待される結果

1. を満たしている。

FLASH30: 画像ボタンにアクセシブルな名前 (accessible name) を指定する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

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

FLASH30 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

画像ベースの Button コンポーネントには、機能的なラベルを提供するためにアクセシブルな名前を設定する必要がある。このラベルはボタンの機能を示すもので、画像を説明するものではない。ページ内に異なる結果をもたらす複数のボタンがある場合、ラベルは特に重要である。

Flash ムービーの使用中にボタンが変更されるときは、ボタンのアクセシブルな名前も更新しなければならない場合がある。

事例

事例 1: シンプルな画像ボタンにアクセシブルな名前を設定する

この事例では、スクリプトによってアイコンベースのボタンにアクセシブルな名前を設定している。ボタンをクリックするとウェブページが開かれる。

コード例:

//画像ボタンのテキスト同等物を提供する
this.check_btn.accessibilityProperties = new AccessibilityProperties();
this.check_btn.accessibilityProperties.name = "Check page validation";

//URLにナビゲートするイベントリスナーと関数を設定する

this.check_btn.addEventListener(MouseEvent.CLICK, onClickHandler);

function onClickHandler(e: MouseEvent): void {
  var btn = e.target;
  var url: String = "http://validator.w3.org";
  var request: URLRequest = new URLRequest(url);
  navigateToURL(request, '_blank');
}

この実例は、シンプルな画像ボタンにアクセシブルな名前を設定するのサンプル (英語) で確認できる。また、シンプルな画像ボタンにアクセシブルな名前を設定するのソース (英語) をダウンロードすることもできる。

事例 2: 動的な画像ボタンにアクセシブルな名前を設定する

コード例:

import fl.controls.Button;
import fl.accessibility.ButtonAccImpl;

ButtonAccImpl.enableAccessibility();

var soundIsMuted = false;
var myButton: Button = new Button();
myButton.label = "";
myButton.x = myButton.y = 10;
myButton.width = myButton.height = 50;
updateAccName(myButton, "mute sound");
myButton.setStyle("icon", unmuted);
myButton.addEventListener(MouseEvent.CLICK, handleBtnClick);
addChild(myButton);

function handleBtnClick(e) {
  soundIsMuted = ! soundIsMuted;
  myButton.setStyle("icon", soundIsMuted? muted: unmuted);
  updateAccName(myButton, soundIsMuted? "unmute sound": "mute sound");
}

function updateAccName(obj, newName: String) {
  if (! obj.accessibilityProperties)
  obj.accessibilityProperties = new AccessibilityProperties();
  obj.accessibilityProperties.name = newName;
  if (Capabilities.hasAccessibility)
  Accessibility.updateProperties();
}

この実例は、動的な画像ボタンにアクセシブルな名前を設定するのサンプル (英語) で確認できる。また、動的な画像ボタンにアクセシブルな名前を設定するのソース (英語) をダウンロードすることもできる。

FLASH1: 非テキストオブジェクトに name プロパティを設定する

検証

手順

Flash ムービーに画像ベースのボタンが含まれている場合は、次のことを確認する。

ボタンのアクションを説明したアクセシブルな名前がボタンに設定されている。
ボタンのアクションが変更された場合 (クリックされた場合など) は、それに応じてアクセシブルな名前も変更される。

期待される結果

1. および 2. を満たしている。

FLASH31: DataGrid の表題を指定する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

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

FLASH31 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、見た目で表題が提供されている場合に、プログラムによって表題をデータグリッドに関連付けることである。通常、テーブルの表題はテーブルの識別子であり、テーブルのタイトルまたは見出しとして機能する。

Flash には DataGrid コンポーネント用の caption 要素はない。ただし、以下のアプローチによって同じ効果を得ることができる。

データグリッドの上にラベルコンポーネント又はテキストフィールドを配置し、グリッドの表題を設定する。
表題のテキストを複製し、グリッドのアクセシブルな名前として追加する。これを行うには、グリッドのアクセシビリティパネルの「名前」フィールドに値を設定するか、又はグリッドの AccessibilityProperties.name プロパティを設定する。

事例

事例 1: データグリッドにラベルを関連付ける

ここでは、Flash Professional でコンポーネントパネルからステージに追加されるデータグリッドの例を示す。また、コンポーネントパネルから表題となるテキストを格納するためのラベル要素も追加される。この表題は Flash のアクセシビリティパネルで使用され、データグリッドのアクセシビリティ用の名前として機能する。

新しい Flash ファイル (.fla) を作成するか、既存のファイルを開いてデータグリッドを挿入する。
ウィンドウメニューから Flash のコンポーネントパネルを開く。
データグリッドコンポーネントをステージ上にドラッグし、目的の位置に配置する。
ラベルコンポーネントをステージ上にドラッグし、目的の位置に配置する。
ラベルコンポーネントにテキストを追加する。
データグリッドコンポーネントを選択し、アクセシビリティパネルを使用して、データグリッドの「名前」フィールドにラベルコンポーネントで使用しているのと同じテキストを追加する。

事例 2: ActiveScript 3 を使用してデータグリッドにキャプションを関連付ける

ここでは、AS3 のスクリプトによってデータグリッドを生成する基本的な事例を示す。また、表題となるテキストを格納するラベル要素も作成する。この表題は、アクセシブルな名前としてグリッドに追加する。

コード例:

import fl.accessibility.DataGridAccImpl;
import fl.controls.DataGrid;
import fl.controls.Label;
import fl.data.DataProvider;
import flash.accessibility.Accessibility;
import flash.accessibility.AccessibilityProperties;
import flash.system.Capabilities;

// データグリッドのアクセシビリティを有効にする
DataGridAccImpl.enableAccessibility();

createGrid();

// データグリッドの表題を設定する
var gridCaptionText: String = "Game Results";
gridCaption.text = gridCaptionText;
//表題をデータグリッドのアクセシブルな名前として追加する
var accProps: AccessibilityProperties = new AccessibilityProperties();
accProps.name = gridCaptionText;
aDg.accessibilityProperties = accProps;
if (Capabilities.hasAccessibility)
Accessibility.updateProperties();

function createGrid() {
  
  //コンポーネントを作成して追加する
  var aDg: DataGrid = new DataGrid();
  var gridCaption: Label = new Label();
  addChild(aDg);
  addChild(gridCaption);
  aDg.move(50, 50);
  gridCaption.move(50, 20);
  
  var captionFormat: TextFormat = new TextFormat();
  captionFormat.size = 24;
  gridCaption.setStyle("textFormat", captionFormat);
  gridCaption.width = 300;
  gridCaption.height = 100;
  bldRosterGrid(aDg);
  //データを準備する
  var aRoster: Array = new Array();
  aRoster =[ 
    {Name: "Wilma Carter", Bats: "R", Throws: "R", Year: "So", Home: "Redlands, CA"},
    {Name: "Sylvia Munson", Bats: "R", Throws: "R", Year: "Jr", Home: "Pasadena, CA"}, 
    {Name: "Carla Gomez", Bats: "R", Throws: "L", Year: "Sr", Home: "Corona, CA"}, 
    {Name: "Betty Kay", Bats: "R", Throws: "R", Year: "Fr", Home: "Palo Alto, CA"},
  ];
  aDg.dataProvider = new DataProvider(aRoster);
  aDg.rowCount = aDg.length;
};

function bldRosterGrid(dg: DataGrid) {
  dg.setSize(400, 300);
  dg.columns =[ "Name", "Bats", "Throws", "Year", "Home"];
  dg.columns[0].width = 120;
  dg.columns[1].width = 50;
  dg.columns[2].width = 50;
  dg.columns[3].width = 40;
  dg.columns[4].width = 120;
};

このコード例に関する注記:

この実例は、ActiveScript 3 を使用してデータグリッドにキャプションを関連付けるのサンプル (英語) で確認できる。また、ActiveScript 3 を使用してデータグリッドにキャプションを関連付けるのソース (英語) をダウンロードすることもできる。
Flash のオーサリングツールのアクセシビリティパネルを使用することによって、データグリッドにアクセシブルな名前を適用することもできる。
上記の事例では、データグリッドの表題として使用されるテキストは 2 回読み上げられる。1 回目は視覚に問題のない利用者向けのテキストラベルとして、2 回目はデータグリッドのアクセシブルな名前としてである。コンテンツ制作者は、ラベルテキストの silent プロパティを true に設定することによって、読み上げが重複するのを回避することができる。

H39: データテーブルのキャプションとデータテーブルを関連付けるために、caption 要素を使用する

検証

手順

Flash ムービーに DataGrid コンポーネントが含まれているかどうかを確認する。
各データグリッドの表題となるテキストが、アクセシブルな名前としてコンポーネントに追加されている

期待される結果

2. を満たしている。

FLASH32: フォームコントロールにテキストラベルを関連付けるために、自動ラベリングを使用する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

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

FLASH32 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

CheckBox コンポーネントおよび RadioButton コンポーネント以外の Flash 標準コンポーネントでは、関連付けられたラベルが自動的に提供されることはない。これらのコンポーネントについては、Label コンポーネントを使用して、コントロールの隣にラベルテキストを手動で配置する必要がある。アクセシビリティパネルで「自動ラベル」機能を有効にしてある場合は、TextInput コンポーネントおよび TextArea コンポーネントについては Flash Player が自動的にラベルテキストを関連付ける。つまり、これらのコンポーネントでは、アクセシビリティパネルを使用してコントロールのラベルテキストを複製する必要はない。自動ラベル機能はデフォルトで有効になっている。

また、自動ラベル機能によって、Flash Player はボタンシンボルに含まれているテキストをシンボルのアクセシブルな名前として自動的に追加することが可能になる。これは、ボタンシンボルがテキストラベルを含む一つのレイヤーだけで構成されている場合のみ有効である。

注記: 自動ラベル機能は人間が操作することなくラベルを関連付けるため、関連付けの正確性を検証する必要がある。予測可能な結果を得るためには、すべてのコントロールに対して明示的にラベルを追加することが推奨される。

次の手順で自動ラベル機能を利用する。

Flash アプリケーションに含まれる各フォームコントロールの近くに、説明テキストが配置されていることを確認する。自動ラベル機能で使用されるテキストは、支援技術からアクセス可能にする必要がある。
ムービーステージを選択し、アクセシビリティパネルを開く。
「自動ラベル」オプションがオンになっていることを確認する。この結果、TextInput コントロールおよび TextArea コントロールにラベルが自動的に関連付けられ、カスタムボタンシンボル内のテキストがアクセシブルな名前として追加される。
自動ラベル動作が適さない Flash コンテンツの場合は「自動ラベル」オプションをオフにし、アクセシビリティパネルで各コントロールに分かりやすい「名前」の値を設定する。
自動ラベル機能を、ムービー全体に対してでなく特定のオブジェクトに対して無効にするには、プロパティインスペクタを使用してテキストのタイプを「ダイナミックテキスト」に変更する。次にそのテキストを選択し、アクセシビリティパネルで「オブジェクトをアクセス可能にする」オプションをオフにする。

注記: アクセシビリティパネルを使用する以外にも、ステージオブジェクトの AccessibilityProperties.noAutoLabel を true に設定することによって自動ラベル機能をオフにすることができる。

事例

事例 1: アクセシビリティパネルで「自動ラベル」オプションを使用する

この事例では、二つの TextInput コンポーネントと、TextArea コンポーネントとカスタムボタンシンボルのインスタンスが一つずつ表示される。各 TextInput コンポーネントには、コントロールの左に個別のラベル要素が配置されている。TextArea コンポーネントには、コントロールの上にラベルが配置されている。カスタムボタンには、ボタンシンボルの内部にラベルテキストが配置されている。アクセシビリティパネルで「自動ラベル」オプションを有効にしているため、すべてのコントロールに対してラベルに基づいたアクセシブルな名前が提供される。

次のスクリーンショットは、この事例を示したものである。画面スクリーンショット: Flashオーサリング環境で自動ラベル機能を使用

この実例は、アクセシビリティパネルで「自動ラベル」オプションを使用するのサンプル (英語) で確認できる。また、アクセシビリティパネルで「自動ラベル」オプションを使用するのソース (英語) をダウンロードすることもできる。

FLASH25: アクセシブルな名前 (accessible name) を設定することによって、フォームコントロールにラベルを付ける

検証

手順

Flash フォームに TextInput コンポーネント、TextArea コンポーネント、またはテキストラベルを使用したカスタムボタンシンボルが含まれている場合、次のことを確認する。

ムービーのアクセシビリティパネルで「自動ラベル」オプションが有効になっている。
スクリーンリーダーまたは MSAA チェッカーを使用して確認すると、ラベルテキストがコントロールのアクセシブルな名前として実際に利用されている。

期待される結果

1. および 2. を満たしている。

FLASH33: Flash オブジェクトのサイズに相対値を使用する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.8 (視覚的提示)
- クイックリファレンス 1.4.8 (視覚的提示)
- 達成基準 1.4.8 (視覚的提示)を理解する
注記: この達成方法は、達成基準 1.4.8 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.4.8 を理解するを参照すること。

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

FLASH33 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、em の値など相対的な単位を使用して、埋め込みの Flash オブジェクトの幅や高さを指定することである。Flash オブジェクトのサイズは、ムービーの幅と高さを 100% に設定することによって、コンテナ (親要素) のサイズに合わせて拡張することができる。コンテナの幅と高さは、相対的な単位を使用して設定する。これにより、テキストサイズの変更をサポートするユーザエージェントは、テキストサイズの設定の変更に応じて Flash オブジェクトのサイズを変更することが可能になる。Flash オブジェクトのサイズが調整されると、そのコンテンツが拡大縮小され、ロービジョンの利用者でも読みやすくなる。

注記: この実装方法では、ブラウザでズーム機能を使用する利用者をサポートする必要はない。

事例

事例 1: 最小限のサイズを維持しながらテキストのサイズを拡大縮小する

この事例では、SWFObject による動的なパブリッシュ手法 (英語) を使用して HTML ドキュメント内に Flash オブジェクトをロードしている。Flash オブジェクトのコンテナ要素には、「flashPlaceHolder」というクラス名が付けられている。このクラス名は、CSS で相対的な em 値を使用して幅および高さを設定する際のターゲットとなる。利用者がブラウザのテキストサイズを増加又は減少させるとき、それに応じて Flash オブジェクトも拡大縮小する。テキストサイズを縮小したときにオブジェクトが小さくなりすぎることがないように、デフォルトのサイズに対して min-width および min-height プロパティを設定している。

コード例:

<!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">
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"/>
    <title>Flash Resize example</title>
    <script src="swfobject/swfobject.js" type="text/javascript"/>
    <script type="text/javascript">
    swfobject.embedSWF("scale_movie_dimensions_on_text_resize_as3.swf", 
    "flashPlaceHolder", "100%", "100%", "8")      
</script>

    <style type="text/css">
  #flashPlaceHolder {
    width: 20em;
    height: 15em;
    min-width: 320px;
    min-height: 240px;
  }
</style>
  </head>
  <body id="header">
    <h1>Flash Resize Demonstration</h1>
    <p>When the browser's text size is changed, the Flash movie will be
      resized accordingly.</p>
    <p id="flashPlaceHolder">Flash needs to be installed for this
      example to work</p>
  </body>
</html>

この実例は、最小限のサイズを維持しながらテキストのサイズを拡大縮小するのサンプル (英語) で確認できる。また、最小限のサイズを維持しながらテキストのサイズを拡大縮小するのソース (英語) をダウンロードすることもできる。

C24: コンテナのサイズに CSS のパーセント値を使用する

検証

手順

Flash オブジェクトが埋め込まれているウェブページを開く。
HTML ソースコードで、Flash オブジェクトが格納されているオブジェクトの幅および高さのサイズが、em またはパーセント (%) などの相対的な単位で指定されている

期待される結果

2. を満たしている。

FLASH34: 支援技術が検出された場合に、自動的に再生される音声をオフにする

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.2 (音声の制御)
- クイックリファレンス 1.4.2 (音声の制御)
- 達成基準 1.4.2 (音声の制御)を理解する

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

FLASH34 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、Flash ムービーがロードされたときに音声が再生されないようにすることである。これは、スクリーンリーダー、スクリーン拡大鏡、スイッチメカニズムなどの支援技術の利用者や支援技術を使用しない利用者 (認知障害、学習障害、言語障害を持つ人々) に役立つ。デフォルトでは、音声は自動的に再生される。ただし、JAWS などのスクリーンリーダーが検出された場合は、音声は手動で開始される必要がある。

Flash は、スクリーンリーダーを検出するための flash.accessibility.Accessibility.active プロパティを提供している。このプロパティが true に設定されている場合は、支援技術が実行されていることを Flash Player が検出したことを意味する。このフラグに基づいて、Flash のコンテンツ制作者は別の機能を実行するように選択できる。

注記 1: Flash Player が、実行されている支援技術を検出し、Accessibility.active プロパティを設定するまでには多少時間がかかる。したがって、正確な結果を得るためには、ムービーの最初のフレームですぐにこのプロパティをチェックしてはならない。5 フレーム後、またはタイムイベントを使用してチェックを行うようにする。

注記 2: このメカニズムでは検出されないスクリーンリーダーも存在する。一般的に、このプロパティが true に設定されるのは、MSAA クライアントが実行されている場合である。

注記 3: 注記 3: 他の支援技術ツール (スクリーン拡大鏡など)、または支援技術としては使用されないツールの中にも MSAA を利用するものがあり、その結果として Accessibility.active が true に設定される場合がある。

事例

事例 1: SoundHandler クラス

Accessibility.active が false に設定されている場合のみ自動的に mp3 ファイルの再生を開始する、SoundHandler というクラスが作成される。この事例では flash.system.Capabilities.hasAccessibility プロパティもチェックしていることに注意する。このプロパティはスクリーンリーダーが実行されているかどうかをチェックするものではなく、Flash Player が MSAA (基本的には Windows オペレーティングシステムを意味する) をサポートする環境で実行されているかどうかを示すものである。

コード例:

package wcagSamples {
  import flash.accessibility.Accessibility;
  import flash.display.Sprite;
  import flash.net.URLRequest;
  import flash.media.Sound;
  import flash.media.SoundChannel;
  import flash.system.Capabilities;
  import fl.controls.Button;
  import fl.accessibility.ButtonAccImpl;
  import fl.controls.Label;
  import flash.events.MouseEvent;
  
  public class SoundHandler extends Sprite {
    private var snd: Sound = new Sound();
    private var button: Button = new Button();
    private var req: URLRequest = new URLRequest(
      "http://av.adobe.com/podcast/csbu_dev_podcast_epi_2.mp3");
    private var channel: SoundChannel = new SoundChannel();
    private var statusLbl: Label = new Label();
    public function SoundHandler() {
      snd.load(req);
      ButtonAccImpl.enableAccessibility();
      button.x = 10;
      button.y = 10;
      statusLbl.autoSize = "left";
      statusLbl.x = 10;
      statusLbl.y = 40;
      addChild(statusLbl);
      button.addEventListener(MouseEvent.CLICK, clickHandler);
      this.addChild(button);
      if (! Capabilities.hasAccessibility || ! Accessibility.active) {
        channel = snd.play();
        button.label = "Stop Sound";
        statusLbl.text = "No Assistive technology detected. \
          Sound will play automatically";
      } else {
        button.label = "Start Sound";
        statusLbl.text = "Assistive technology detected. \
          Sound will not play automatically";
      }
    }
    private function clickHandler(e: MouseEvent): void {
      if (button.label == "Stop Sound") {
        button.label = "Start Sound";
        channel.stop();
      } else {
        channel = snd.play();
        button.label = "Stop Sound";
      }
    }
  }
}

この実例は、SoundHandler クラスのサンプル (英語) で確認できる。また、SoundHandler クラスのソース (英語) をダウンロードすることもできる。

参考リソース

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

G170: 自動的に再生される音声を停止するコントロールを、ウェブページの先頭付近で提供する

検証

手順

MSAA をサポートしているスクリーンリーダーを起動する。
スクリーンリーダーが実行されていない場合は、自動的に音声を再生する Flash ムービーが含まれているページを開く。
音声の再生が停止している。

期待される結果

3. を満たしている。

FLASH35: Flash コンテンツをスクロールさせて、それを停止させるメカニズムを提供するために、スクリプトを使用する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.2 (一時停止、停止、非表示)
- クイックリファレンス 2.2.2 (一時停止、停止、非表示)
- 達成基準 2.2.2 (一時停止、停止、非表示)を理解する

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

FLASH35 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、コンテンツのスクロールがスクリプトによって生成された場合に、そのスクロールを停止する方法を利用者に提供することである。コンテンツをスクロールさせると、ロービジョンの利用者または認知障害を持つ利用者にとって読解が困難または不可能になる場合がある。また、利用者によっては、スクロールの動きに気を取られてしまい、ウェブページの他の部分に集中できなくなる場合がある。

事例

事例 1: スクロールの一時停止と再開を行うためのトグルボタン

この事例では、テキストを左から右にスクロールさせている。利用者がこのスクロール動作を停止および再開できるようにするためのトグルボタンが用意されている。また、スクロールの速度を落とすためのチェックボックスも用意されている。

注記: スクロール速度のオプションについて、この事例で紹介されているよりも多くのオプションを希望する利用者もいる。こうした要求を満たすために、コンテンツ制作者はスライダやドロップダウンリストなどのコントロールを使用して、複数の速度オプションを提供することも可能である。

コード例:

import fl.accessibility.ButtonAccImpl;
import fl.accessibility.CheckBoxAccImpl;

ButtonAccImpl.enableAccessibility();
CheckBoxAccImpl.enableAccessibility();

var scrollInterval: int;
var intervalLength: int = 15;

var expandedViewer: MovieClip = exampleScroller.expandedViewer;
var scrollText: MovieClip = exampleScroller.scrollText;
var scrollViewer: MovieClip = exampleScroller.scrollViewer;

var scrollingPaused: Boolean = true;

scrollStopper.addEventListener(MouseEvent.CLICK, handleBtnClick, false);
slowDown_chk.addEventListener(MouseEvent.CLICK, handleChkClick, false);

function handleBtnClick(e) {
  toggleScroll(false);
  e.target.label = scrollingPaused? "Resume Scrolling": "Stop Scrolling";
}

//スクロール速度を下げる
function handleChkClick(e) {
  intervalLength = e.target.selected? 50: 15;
  if (! scrollingPaused) {
    clearTimeout(scrollInterval);
    toggleScroll(true);
  }
}

//スクロールを一時停止または再開する
function toggleScroll(noToggle: Boolean) {
  if (noToggle || scrollingPaused)
  scrollInterval = setInterval(moveText, intervalLength); else
  clearTimeout(scrollInterval);
  if (! noToggle)
  scrollingPaused = ! scrollingPaused;
}

function moveText() {
  if (scrollText.x + scrollText.width < scrollViewer.x)
  scrollText.x = scrollViewer.x + scrollViewer.width;
  scrollText.x -= 1;
}

//スクロールを開始する
toggleScroll(false);

この実例は、スクロールの一時停止と再開を行うためのトグルボタンのサンプル (英語) で確認できる。また、スクロールの一時停止と再開を行うためのトグルボタンのソース (英語) をダウンロードすることもできる。

G4: コンテンツを一時停止させて、一時停止させたところから再開できるようにする

検証

手順

Flash ムービーにスクロールするコンテンツが含まれている場合、次のことを確認する。

利用者がスクロールを一時停止したり再開したりすることのできるボタンが提供されている。
ボタンを押すと、スクロールが停止する。
もう一度ボタンを押すと、スクロールが再開する。

期待される結果

1., 2. および 3. を満たしている。

FLASH36: 点滅を制御し、5 秒以内に点滅を停止させるために、スクリプトを使用する

適用 (対象)

Adobe Flash Professional バージョン MX 以降
Adobe Flex

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.2 (一時停止、停止、非表示)
- クイックリファレンス 2.2.2 (一時停止、停止、非表示)
- 達成基準 2.2.2 (一時停止、停止、非表示)を理解する

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

FLASH36 に関するユーザエージェントサポートノートを参照のこと。Flash テクノロジーノートも参照。

解説

この実装方法の目的は、スクリプトを使用して点滅を制御し、点滅を 5 秒以内に停止させることである。ActionScript の setTimeout() メソッドを使用して、ムービークリップの点滅動作を 5 秒以内に停止させる。

事例

事例 1: タイムアウト後に点滅を停止させる

この事例では、ムービークリップ (blinkingTextMC) でタイムラインを使用して点滅効果を生成している。5 秒経過する前にムービークリップの gotoAndStop() メソッドが呼び出され、このメソッドにより点滅が停止する。

コード例:

setTimeout(stopBlinking, 4500);
function stopBlinking() {
  var blinkingTextMC = getChildByName('blinkingTextMC');
  blinkingTextMC.gotoAndStop(1);
}

この実例は、タイムアウト後に点滅を停止させるのサンプル (英語) で確認できる。タイムアウト後に点滅を停止させるのソース (英語) をダウンロードすることもできる。

検証

手順

点滅するコンテンツのインスタンスすべてについて、次のことを確認する。

点滅が開始したら 5 秒経過するまで待つ。
5 秒経過した時点で、点滅が停止する。

期待される結果

点滅するコンテンツのインスタンスすべてについて、2. を満たしている。

10. Silverlightの達成方法

Silverlight Technology Notes

訳注: Silverlight は、2021 年 11 月にサポートを終了する計画が Microsoft 社より公表されている (Microsoft サポート - Silverlight のライフサイクルポリシー)。

WAIC では、Silverlight に関する達成方法の翻訳を行っていないが、将来もその予定がないことに留意されたい。

Microsoft Silverlight is a development platform for applications. To learn more about Silverlight and how Microsoft defines and markets the Silverlight technology, see What Is Silverlight? document on microsoft.com.

Once an application author produces a Silverlight application, the most common way to deploy that application is to present the Silverlight content using a browser plug-in that end users have installed on their computers. The Silverlight plug-in is instantiated within an HTML page as an <object> or <embed> tag. <object> tag attributes reference Silverlight's unique classid, and/or its MIME type, thus invoking a plug-in instance within the browser host's HTML content. Users request the Silverlight-containing page as a URL, and the surrounding HTML plus the Silverlight content is viewed within a browser host such as Firefox, Internet Explorer, Google Chrome, or Safari. There are other means by which Silverlight-developed content can be deployed that are NOT viewed in the plug-in or hosted by HTML; this is discussed in the upcoming section "Browser Host Platform Considerations".

The content that is displayed within the Silverlight content area is specified as the "source" parameter, within the Silverlight object/embed tag. The "source" parameter value references a URI for a package. The package is typically served by the same server that served the HTML (and the package itself is typically requested through http: or https: protocol). The package always contains an application manifest, and a managed code compiled DLL. The package might also contain other content, for example media files or image files that the application consumes as resources. The compiled DLL typically contains two types of information within its compiled structure: CLR runtime code that handles dynamic operations of the application such as startup logic, business rules, event handlers, and further resources. The resources inside the DLL are primarily UI definitions in a markup format/language called XAML.

Silverlight provides a combination of built-in support for accessibility and capabilities that authors and authoring tools can take advantage of in order to enable support for accessible content. Tools and related technologies that are related to this include:

Microsoft Visual Studio 2010 (or Microsoft Visual Studio 2008 if still developing for version 3 of the Silverlight runtime) – Silverlight authors can use Express versions if their development needs are fairly basic
Microsoft Expression products, in particular Microsoft Expression Blend
Silverlight Tools – a separate package for Visual Studio that should be installed for effective Silverlight application development
Developer tools that are specifically for verification of information presented to either the UIA or MSAA accessibility frameworks.

Accessibility Frameworks

Silverlight support for assistive technologies is based on implementing Silverlight for Microsoft UI Automation (often abbreviated as UIA). In the UIA accessibility framework, Silverlight is implemented as a UI Automation server. This means that Silverlight provides information about the application itself and its current content through the framework. Any subscriber to the operating system's automation can consume that information as a UI Automation client. One such client role is typically implemented by assistive technologies, most notably by screen readers. By acting as a UI Automation client, an assistive technology can programmatically determine many aspects of Silverlight content and content structure. In addition, UIA has APIs that can change the content in a predictable way that maintains security boundaries between applications. Reading information from Silverlight through the UIA accessibility framework requires no extra work on the part of a given assistive technology, presuming that the assistive technology has already implemented UIA. All information that Silverlight reports to UIA comes through the common property set, and a fixed set of possible user interactions is programmatically accessible through a discoverable set of automation patterns and techniques.

As an example of how UI Automation might provide information to an assistive technology, consider the following scenario:

A Silverlight application author produces an application that follows all Microsoft-documented best practices for providing accessibility information, either by specific programming actions or by relying on a known set of Silverlight default behaviors (many of these actions/behaviors are also described as Silverlight WCAG techniques).
A user views a Web page that contains Silverlight content, using a browser host that loads the HTML, and using an operating system such as Microsoft Windows (XP, Vista or Windows 7) that supports UI Automation.
An assistive technology that is already running on the user's system loads the UIA representation of all Web content loaded by the browser. Part of that representation is an automation element that represents the Silverlight plug-in. The plug-in content area itself is focusable in the browser host's HTML rendering and representation model.
The user navigates elements in the Silverlight application area, either by using the TAB sequence, or by using navigation techniques implemented by a particular assistive technology.
By forwarding information that is pertinent to either the navigated-to element or the application in general, the accessibility framework provides the assistive technology with the information from Silverlight application. As a specific example, a screen reader might read the name and role of the currently focused control element such as a Silverlight TextBox. In addition, the assistive technology can provide means to enter data or otherwise interact with elements of that application, if that element reports to UIA that it supports such interaction.

A good introductory topic on UI Automation is available on MSDN.

UI Automation supersedes Microsoft Active Accessibility (MSAA), an earlier Microsoft accessibility framework. UI Automation provides built-in bridging support for MSAA, such that assistive technologies that are implemented as clients for MSAA rather than UIA receive the expected interface hooks for IAccessible and can call methods of the MSAA interfaces. Also, applications that provide MSAA/ IAccessible are readable to a UIA-client assistive technology through similar bridging.

Whether implemented as clients for UI Automation or for MSAA, support for assistive technologies is provided for users viewing content using combinations of:

Microsoft Internet Explorer 6 or later, in combination with Microsoft Silverlight on Windows.
Mozilla Firefox 3 or later, in combination with Microsoft Silverlight on Windows.
Google Chrome 4 or later, in combination with Microsoft Silverlight on Windows

Screen reader assistive technology support for either MSAA or UIA is provided in several assistive technologies, including but not limited to:

JAWS
Windows-Eyes
NVDA
Microsoft Narrator

The exact level of support to assistive technologies will partially depend on whether that assistive technology is implemented as a UIA client or an MSAA client. This can vary depending on specific version releases of the assistive technology. In general, the UIA architecture is capable of reporting a richer information set to clients than is MSAA. This is because UIA has a larger number of properties available, and also because UIA has the patterns concept to support class extension whereas MSAA does not (class extension is a key concept in Silverlight programming).

Silverlight uses UI Automation support as a general system that addresses parts or entireties of many WCAG criteria at a system/platform level, rather than requiring each Silverlight author to build the entirety of such support as an individually coded feature of a Silverlight application. The following is a list of criteria where UI Automation support in Silverlight is necessary to apply the Silverlight WCAG techniques, and the application must be on a client and platform that also supports UIA (or MSAA):

The following is a list of criteria where UIA Automation support in Silverlight is helpful but not necessary:

Further notes on Name Role Value

Success Criterion 4.1.2 (Name Role Value) directly influenced the design of both the Microsoft UI Automation accessibility framework and its MSAA predecessor. Many aspects of providing name, role and value are built-in to the Silverlight UIA support, and that information can be programmatically determined by assistive technologies that are programmed as UI Automation clients.

Name

In most cases, the name of the control is used to identify that control to users, as well as providing a programmatic identifier. In UI Automation programming, any entity that can have a name is represented as an AutomationElement, and its name is determined by reading the value of the AutomationElementInformation.Name property. There is an intermediate "Current" property, so an example usage is something like:

string AName = anAutomationElement.Current.Name;

Name is the most common UI Automation property that is consumed by assistive technologies. Application authors in general that rely on UI Automation (and Silverlight application authors in particular) typically provide strings for Name that can inform users of the purpose that the element serves in the application. For example, if an application provides a button that can be activated, the Name reported to UI Automation could best describe its purpose by using a Name string something like "Submit form". While there is some crossover here with the concept of Value, what is notable about Name is that it is controlled only by the application rather than typical means of user input that would alter the data of Value.

Because UI Automation is also used as a framework for automation testing of applications, UI Automation supports a parallel identification property named AutomationId. AutomationID is not relevant to accessibility support scenarios, although in practice Name and AutomationID sometimes use the same string values, or are supported by parallel property-forwarding techniques by implementing technologies. The intended design difference between AutomationId and Name is the following:

AutomationID is not intended to be human readable, but is intended to be unique
Name is intended to be human readable but might not be unique

Silverlight in particular has a property-forwarding technique whereby the Silverlight-specific Name or x:Name properties are promoted as the initial AutomationElementInformation.Name. This forwarding is implemented within build procedures to provide a fallback for testing and initial development of an application's UI Automation representation. In many cases a forwarded Name/x:Name does not result in a particularly human-comprehensible or user-actionable string or phrase. Silverlight application authors should use a test-based methodology to examine all possible AutomationElementInformation.Name values exposed by their application, and assure that each such string is specifically replaced by a UI-specific AutomationProperties.Name value.

Role

Role in UI Automation can be determined through several techniques.

The most straightforward technique for determining a given AutomationElement's role is to check the value of ControlType. This value provides an enumeration that reports role as several known possibilities plus an alternate role of "Custom" if no enumeration-defined role is a good descriptor. For example, a Silverlight Button control describes itself to UI Automation as a ControlType of Button, and a Silverlight TreeView describes itself as Tree.

For further information on roles, UI Automation clients can query an AutomationElement to see which UI Automation patterns that element supports. The patterns describe expectations of the interaction model, and the patterns themselves expose the methods that clients should call to engage that interaction. For more information, see Get Supported UI Automation Control Patterns on MSDN.

Value

In MSAA, the "Value" concept was addressed by the simple property Value and had to be represented as a string. One of the major refinements of UIA over MSAA is to expand what types of data can be expected to exist as a value. For this reason, determining "Value" requires a larger understanding of UI Automation and how to access UI Automation patterns exposed by each peer, and is not discussed further in this document. For more information, see Get Supported UI Automation Patterns and UI Automation Control Patterns for Clients. The most basic concept of Value is often represented by the ValuePattern, but UI Automation clients should be aware of the larger range of patterns that can possibly return or provide a value. In general, the UIA Value pattern is only relevant for setting the value directly, such as in a text box where a user types or otherwise inputs a string or phrase.

State is also a related concept to value. UI Automation elements typically report states that make sense given their role, and such state is reported in the provider implementations. There are also some generalized state properties available in any automation element. Examples of these include: HasKeyboardFocus; IsOffscreen.

Object Tree Concepts and UI Automation Tree Views

The object tree is composed of all the programming constructs that a Silverlight application author explicitly declares by writing XAML UI definitions (which are initially loaded by the Silverlight runtime) and by invoking run-time code. The relationships between nodes in XAML markup, and the declaration order of peer elements in XAML, create identical relationships/orders in the object tree representation. In code, order is made explicitly by using structured definitions and APIs of various types of collections (list, dictionaries, etc.) that are common in .NET Framework programming. For example, to get the first child of a StackPanel named myPanel, call myPanel.Childen[0] (.NET collections are zero-index based). Parent-child relationships are declared by how specific properties are set. For example, to add a "newButton" child element to myPanel as the last child, call myPanel.Children.Add(newButton).

An object tree representation forms the basis of the Silverlight run-time programming model, and enables programmatic access to every programming entity or element part of a running Silverlight application. The object tree representation is particularly useful for accessibility frameworks, and in turn for assistive technologies that use the accessibility framework as a client. The relationships and item order in the object tree also define the default reading order, as well as the default tab sequence for default Silverlight key handling. The Silverlight plug-in code that renders Silverlight content into the plug-in display area is literally reading the same run-time object tree that is being simultaneously reported to the accessibility frameworks or other subsystems of Silverlight (for example, printing APIs).

Silverlight supports UI Automation (UIA) as its primary accessibility framework on Windows platform. Silverlight also provides accessibility information to MSAA, by reporting information through the UIA-MSAA bridge. By using the APIs of the relevant accessibility framework, assistive technologies and other accessibility framework clients can discover the information and relationships declared in a Silverlight application's runtime object tree. The accessibility framework APIs work against the UI automation tree in a manner that does not require any specific knowledge of the Silverlight programming model. For example, the UI Automation APIs use an abstraction of a UIAutomationElement to represent any accessible Silverlight object. By calling UI Automation APIs against this abstracted object, accessibility framework clients can determine any child elements and their count, check parent elements, can obtain name/role/value of that UIAutomationElement, and so on. In fact, Silverlight accessibility support in general is achieved without assistive technologies even being aware that Silverlight is a distinct technology from HTML. This is because Silverlight implements its accessibility framework support such that Silverlight dovetails into the surrounding HTML content through the connection point of the "SilverlightControl" UIAutomationElement that exists within the browser host's HTML content.

For more information, see UI Automation (unmanaged) or UI Automation (managed)

An Object Tree / UI Automation Example

In the following XAML example, a Silverlight StackPanel is the container element for four different Button elements. In the visible user interface, the resulting buttons are oriented vertically, with the first declared button vertically above the others and first in the tab sequence. (Event handling logic for each button is not shown and is not relevant for the example.)

<StackPanel Orientation="Vertical" > <Button>Hit</Button> <Button>Stay</Button> <Button>Split</Button> <Button>Double Down</Button> </StackPanel>

The following image shows the resulting render order. Note the first “Hit” button has the blue border as focus indicator; focus was placed here by traversing the default tab order, and this element was the first Silverlight element that captured the focus.

Image:StackPanelButtonsOrder.png

The following is the same UI as defined in C# code rather than XAML. The key concept here is that each call to a Silverlight collection Add method adds that item to the end of the existing collection. Thus, to define a collection’s order, add the intended first item with the first call to Add, the second item in the next line of code, and so on. This code is analogous to what a XAML parser does when it processes the previous XAML example, and results in the same visible UI and same default tab order.

void MakeUI() { StackPanel sp = new StackPanel() { Width = 300, Orientation = Orientation.Vertical }; Button hitButton = new Button() { Content = "Hit" }; Button stayButton = new Button() { Content = "Stay" }; Button splitButton = new Button() { Content = "Split" }; Button doubleDownButton = new Button() { Content = "DoubleDown" }; sp.Children.Add(hitButton); sp.Children.Add(stayButton); sp.Children.Add(splitButton); sp.Children.Add(doubleDownButton); }

The following is a screenshot of the UI Automation subtree specifically in the area of the UI as declared by either the XAML or C# shown previously. The tool being used in this screenshot is Inspect.exe, which comes with the Windows SDK version 7.1

Image:Screenshot_uia_objecttree.png

The screenshot is representative of the kind of tree structure that a UI Automation client such as a given assistive technology is able to program against, when a Silverlight application exists as an embedded plug-in inside the surrounding browser host.

Input and Multimedia

Silverlight implements UI controls that support keyboard input methods for users who do not use a mouse. Also, Silverlight provides the input system framework such that application authors and control authors can provide similar mouse-keyboard equivalence from their own UI, by using the Silverlight event system and sending each event to the same or similar handling logic. Silverlight application authors can control the tab order of content within Silverlight content, as is demonstrated in the WCAG 2.0 techniques for Silverlight.

Silverlight is often used to display video. Silverlight and the media formats it supports can include embedded text tracks with timing markers. The text tracks and timing markers enable a Silverlight technique that can provide closed captions or subtitles in any language. Silverlight and its media formats also support multiple tracks of audio, thereby enabling support for video description.

Text and Color Preferences

Silverlight supports text resize through browser zoom, as described in G142: Using a technology that has commonly-available user agents that support zoom. The effects of invoking browser zoom apply any resize to the entirely of the hosted HTML (including Silverlight content). Silverlight interaction with browser zoom is further discussed in the Silverlight WCAG technique SL22: Supporting Browser Zoom in Silverlight.

However, not all browser hosts that are supported by Silverlight provide browser zoom as a feature, and in the Firefox implementation the text within the Silverlight content area is not affected if the user has checked Zoom Text Only. As an alternative or additional technique for text resize, the Silverlight WCAG technique SL23: Using A Style Switcher to Increase Font Size of Silverlight Text Elements describes how to use Silverlight APIs to resize text elements that are specifically within the Silverlight content area.

Silverlight supports a high-contrast detection mode at the platform level. If the user has already selected a high-contrast mode at the platform/OS level, the Silverlight application can use various styling and appearance techniques to select a color scheme that is appropriate for high contrast. This concept is shown in the Silverlight WCAG technique SL13: Providing A Style Switcher To Switch To High Contrast. Silverlight and its API do not account for any color settings that are made for default HTML by a browser host application (settings under General / Appearance in Internet Explorer; settings under Content / Fonts & Color in Firefox). This information is not made available to plug-ins such as Silverlight.

User Agents Supported

Silverlight documents its official list of supported user agents on the Microsoft.com web site. The list is dynamic, because the vendors that produce browsers are constantly updating versions. Also, Silverlight might announce support for a browser in a time period that falls after the release date of the latest Silverlight runtime; sometimes this means that the Silverlight product team performed new testing for acceptance of that specific user agent and can now vouch for an official level of Microsoft support.

For convenience, a snapshot of the official Microsoft browser/user agent support matrix from the date 13 January 2011 is reproduced here:

Windows Vista: IE 8, IE 7, Firefox 3, Chrome 4
Windows 7: IE 8, Firefox 3, Chrome 4
Windows Server 2008: IE 8, IE 7, Firefox 3, Chrome 4
Windows Server 2008 R2: IE 8, Chrome 4
Windows Server 2003, Windows XP SP2, SP3: IE 8, IE 7, IE 6, Firefox 3, Chrome 4
Windows 2000 SP4 + KB 891861: IE 6
Macintosh OS 10.4.11+ (Intel-based): Firefox 3, Safari 3, Safari 4

For the official list of supported user agents for Silverlight, see http://www.microsoft.com/getsilverlight/get-started/install/default.aspx (System Requirements tab).

As of 13 January 2011 Silverlight does not work in 64-bit browser hosts (64-bit platform users should use a 32-bit browser application on their system).
Silverlight and Novell have a technical collaboration, and Novell sponsors an open-source initiative known as the Mono Project. Part of the Mono Project is Moonlight, which is a port of Silverlight technology for Linux and other Unix/X11 based operating systems. For more information, see Mono and Moonlight Supported Platforms.

Browser Host Platform Considerations

Depending on the browser host being targeted, Silverlight is implemented as an ActiveX control or as an NPAPI plugin. When a user installs Silverlight, they are installing both of these implementations, such that the same Silverlight installation could be accessed by an Internet Explorer browser host and a Firefox browser host, and could even be accessed simultaneously by both. Differences between the program access layers of ActiveX versus NPAPI, and also browser-specific differences in program access layers, produce some platform differences that occasionally relate to accessibility support. For example, there can be slight differences in whether the program access layer will correctly forward certain keys or key combinations, which might impact keyboard-mouse equivalence implementations.

Silverlight also supports modes that do not rely on a browser host at all. In previous releases of Silverlight, Silverlight was defined as a platform for producing rich Internet applications. This is still true, but in the current Silverlight release the deployment options are expanded such that a Silverlight application is not necessarily a web-based application, and Silverlight is not exclusively a Web content technology.

Silverlight supports an out of browser deployment mode. Through UI in an initial Web-based Silverlight application, the user is asked to conform whether they wish to install the out-browser application. If the user approves the installation, the Web-based Silverlight application shuts down and the installation begins. Typically, the application restarts itself immediately after the installation. Once installed on the user's hard disk, a Silverlight out-of-browser functions more as an application window under the control of the current platform operating system. This is manifested through technical aspects such as a change in programming security boundaries, and addition of operating-system-specific application model features for the Silverlight out-of-browser application. Examples of the latter include icons and presence in running-application UI metaphors such as task bars. Out-of-browser mode is not specifically mentioned in the Silverlight WCAG techniques, because in this mode Silverlight is no longer a Web application. However, an out-of-browser Silverlight application can include an embedded control that is itself capable of displaying HTML. In this situation, Silverlight accesses basic HTML browser frameworks provided by the platform, and any techniques that would normally apply to HTML content and Web content could also apply to the HTML as viewed within a Silverlight out-of-browser application. For more information, see MSDN.

Silverlight is also a development platform that can be used to create applications for Windows Phone. While these applications often rely on Internet connectivity, these applications are run in the context of an application directly under the Windows Phone operating system, rather than being run in an intermediate Web host that serves as a generalized Web browser for Windows Phone. Therefore the typical considerations of Silverlight acting as a part of a larger definition of Web content do not apply. For more information on Silverlight for Windows Phone development, see The Silverlight and XNA Frameworks for Windows Phone on MSDN.

The XAML Language

XAML is an abbreviation for eXtensible Application Markup Language. In the Silverlight application model, XAML is generally used for defining the elements that make up an application's user interface (UI). XAML markup for UI resembles markup paradigms for HTML in that it uses angle brackets in its syntax, has concepts of elements and attributes, and uses a predominately text-based file editing and storage format such that XAML is human-readable in a text editor. The UI design role typically designs an application user interface by interacting with graphical user interface tools such as Microsoft Expression Blend. In this case, Expression Blend produces XAML as its output, and XAML becomes the interchange format between the Expression Blend tool and the Visual Studio tools. Visual Studio is more typically used by code-oriented Web developers for Silverlight. Web developers in Visual Studio might work with XAML at the text level, and write or change the XAML markup, and more than one interchange between tools and/or roles of a given XAML file might occur by the time the application is finished. The Silverlight techniques are written from the perspective of the code-oriented Web developer who is possibly adjusting post-design phase XAML.

One key difference between HTML and XAML is that XAML is always interpreted by the Silverlight runtime, or preparsed at compile time within Silverlight tools. XAML is NOT parsed by potentially different engines per browser host. Because XAML provides UI definition, the Silverlight techniques often include procedures or concepts that adjust the elements and attributes of XAML markup for an application. Some of the techniques show procedures or concepts for code-behind, scripting, deployment steps, or other aspects of Silverlight programming in addition to or instead of XAML examples. The runtime parsing characteristics of XAML for Silverlight is discussed further in the Silverlight WCAG technique SL33: Using Well-Formed XAML to Define a Silverlight User Interface.

XAML attributes sometimes specify strings that are visible in UI and reported to assistive technologies. The Silverlight WCAG techniques typically hard-code such UI strings in XAML, so that the example code can be kept simple and can concentrate on the immediate concept being illustrated. However, hard-coding UI strings in XAML is not a best practice for production code, because of localizion considerations. To learn more about producing XAML that is localization-ready, or about refactoring XAML to support better designer-coder-localizer workflows, see Localizing Silverlight-based Applications on MSDN.

Test-based Methodology for Accessibility Support

Some of the Silverlight WCAG techniques mention a concept of "test-based methodology" - this section describes what is meant by that concept.

In typical Web application development, there are phases that are a natural part of the workflow. First there is a specification phase, where the basic planning is performed. The next two phases are user interface design (often interweaved with user experience design) and code development. For larger applications or applications that are built on frameworks, the human role of designer is often separate from the human role of code developer/script developer. For this reason the UI design phase and code phase might be going on concurrently, and/or might be iterative. At the point where the efforts of UI design and code development are combined into a working application, many Web developers now introduce a testing phase. It is at this point that a test-based methodology for accessibility support becomes an appropriate and useful strategy.

Testers for Web applications sometimes rely largely on ad hoc or experiential tests, but increasingly there are tools available that assist with the job of testing a Web site. Many of these tools focus on specific aspects of testing: sub-areas such as testing under specific browser hosts; testing with stored state or data vs. initial experience; testing for different form factors; etc. One such sub-area of testing is testing the existing accessibility support.

Because Silverlight supports the UI Automation accessibility framework, the best tools for testing accessibility support in a Silverlight application are the tools that work with UI Automation as their basis. Some of these tools are available from Microsoft, and other such tools are available from third parties.

In a test-based methodology, a tester should view the application in its UIA representation. Using tools, testers can write tests for certain conditions and determine whether the application as a whole passes or fails. For example, a scripted test could determine whether all the controls in a UIA view have a valid string for Name. No Name string would potentially cause an assistive technology to misrepresent that element, and could cause confusion for user groups that rely on a particular assistive technology view of an application. In cases where an application failed these kinds of tests, the application might be sent back to the human role of developer/script writer, so that the missing accessibility information can be committed to the application code base. Then the application can be re-tested.

A test-based methodology for accessibility support works best because Silverlight is such an extensive development platform. Sometimes it is not immediately obvious to a developer that a certain property required for accessibility remained unset. Or perhaps that developer was expecting that the human design role would have introduced that information as part of UI definition. Only when the integration of UI design and code is complete is it possible to see that there is still information or functionality missing. When the development process includes a testing step wherein dedicated tests for accessibility support are committed in a systematic way, it is much more likely that issues can be detected prior to application deployment.

Running Silverlight Test Files Provided with Techniques

Most Silverlight WCAG Techniques reference one or more ZIP files from the Test Files section of the technique. These ZIP files are linked from the techniques and can be uploaded for testing.

To run the test files, you must have Microsoft Silverlight (the client run-time version) installed on your computer. To install Microsoft Silverlight, open the following URL: http://www.microsoft.com/getsilverlight/ . Follow the instruction steps on the Web page. When you install Silverlight, you are installing the plug-in for use by all supported browser user agents on that computer. In order to test techniques that rely on UIA, you should install Silverlight on a computer that is running Microsoft Windows (XP SP2; Vista; Windows 7) as the operating system. Note that you must be running as adminstrator in order to install Microsoft Silverlight on the computer.

Each ZIP file contains two items: an HTML file, and a Silverlight package file (always has a file extension of XAP). You can run any given test file through the following procedure:

Click the link from the technique to download the ZIP file.
Extract all files within the ZIP file to a temporary location, but use a tangible location such as C:\temp rather than temporary Internet files. Do not attempt to open the HTML file from within the unextracted archive; the test will only run correctly when the test components are extracted from ZIP.
Go to the folder location where you extracted the files. To run the test based on the current system's file associations for HTML, open the HTML with the associated browser. Otherwise, you must open the specific browser you want to test under, and type or copy either a file:/// URL or a Windows folder path into that browser's address bar.
This should open the HTML page. When the HTML page opens, it instantiates a Silverlight plug-in within the page content, which in turn references the other extracted file (the XAP) as local content.
Once the content is in view, follow the remaining steps that are indicated in the specific test procedure.

Using Sample Code in Techniques to Create a New Silverlight Application

The Silverlight techniques offer pre-built test files so that you can observe the basic operation of a technique without having to write the code yourself, or create your own application. The salient parts of Silverlight code or Silverlight XAML for the technique are provided as code blocks under the Examples section. In order to experiment more with the technique beyond running the test file, you might want to define your own Silverlight application project, and then import the code and XAML from the technique into your own project. This section describes the basic information that is necessary to create a project that incorporates sample code from a Silverlight technique.

Prerequisites

Creating a Silverlight application project requires that you have a full Silverlight application development environment installed. Although Silverlight applications run cross-platform, the actual development of Silverlight applications is done on Microsoft Windows computers. The computer must have Microsoft Visual Studio 2008 or Microsoft Visual Studio 2010 installed. With some limitations, the Express SKUs of Visual Studio are adequate for basic Silverlight application development. The Express SKUs are available for 30-day evaluation from the following URL: http://go.microsoft.com/fwlink/?LinkId=323467 . In addition to Visual Studio, you also should install the Silverlight Tools, which includes the Silverlight SDK. Get Silverlight Tools from http://go.microsoft.com/fwlink/?LinkID=177428. What to install for Silverlight development is also linked to and explained at Silverlight.net.

Creating the Project

For general instructions, see How to: Create a New Silverlight Project. This creates a new project based on a default template.

The C# code or XAML shown in the Silverlight techniques is a usually a fragment that you should integrate into an existing code file or XAML page from the default project template. For code, you generally open the file page.xaml.cs from Solution Explorer, and paste the entirety of the example code into the body of the C# public partial class that you start with (this class comes from a template). For XAML, you generally open page.xaml from Solution Explorer and paste the entirety of the XAML into the <Grid> element. In some cases the example XAML is the entire XAML (you can identify this case if the example XAML contains one or more xmlns attributes). In this case, replace the entirety of the XAML. However, you may have to adjust the value of the x:Class attribute to properly reference your own partial class; this name is influenced by your own project naming in your local project and thus cannot be anticipated by the example code. Descibing Silverlight application development in its entirety is well beyond the scope of this document. Use resources available from Silverlight.net or MSDN Silverlight documentation to learn more about Silverlight application development.

Special Considerations for WCAG 2.0 Compliance

2.4.2 Page Titled - In order to meet 2.4.2, Silverlight content must be embedded within an HTML page that has a page title in the HTML title element.

3.1.1 Language of Page - The language of an HTML page is established by the Lang attribute of the containing object element in HTML. However, Silverlight's own logic generally interprets language/culture information using a Microsoft .NET Framework concept of the CultureInfo object. This makes it important to align the HTML-level lang with any CultureInfo as used by Silverlight. The reason for this is that assistive technologies are likely to respect the top-level declaration of the Lang attribute and to not be aware of the CultureInfo considerations of embedded Silverlight content. Application authors can delibrately override language settings of a client by specifying a discrete CultureInfo in the Silverlight <object> parameters; this can be useful if the application has real-time language switching, if users store language preferences either locally or based on server information or cookies, etc. Aligning html-lang with CultureInfo and adjusting the CultureInfo through various means are both discussed in Silverlight techniques.

SL1: Accessing Alternate Audio Tracks in Silverlight Media

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

達成基準 1.2.3 (音声解説、又はメディアに対する代替 (収録済) )
- クイックリファレンス 1.2.3 (音声解説、又はメディアに対する代替 (収録済) )
- 達成基準 1.2.3 (音声解説、又はメディアに対する代替 (収録済) )を理解する
注記: この達成方法は、達成基準 1.2.3 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.2.3 を理解するを参照すること。
達成基準 1.2.5 (音声解説 (収録済) )
- クイックリファレンス 1.2.5 (音声解説 (収録済) )
- 達成基準 1.2.5 (音声解説 (収録済) )を理解する
注記: この達成方法は、達成基準 1.2.5 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 1.2.5 を理解するを参照すること。

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

SL1 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to show how to access an alternate audio channel in a prepared media file that is played in a Silverlight MediaElement.

Silverlight supports media file formats that contains additional audio channels in synchronization, beyond the two tracks for stereo audio that are used by typical media player defaults. Silverlight provides a dedicated AudioStreamIndex API on MediaElement, so that the Silverlight application author can use Silverlight programming techniques to select which audio channel to play for the user. Silverlight control authors might label a UI control with text such as "Activate this button to listen to an audio-only version of the media presentation" so that the purpose of the media element control interface is clear to the user. That way the same media control can be used to present the media either as audio-video or as audio-only with alternate track depending on user preference at run time.

The media formats that are supported by Silverlight are documented on MSDN.

Media encoding

The process of encoding the media with additional audio channels is not described in this technique because configuring and encoding audio channels for media formats is a technique for any usage of media in a computer application, not just a Silverlight-specific technique or a Web technology technique. For more information on one possible procedure for encoding the media in WMV format, see Microsoft Expression Encoder Overview. Often, Silverlight authors will receive the media from a third party, such as a video production facility, and are not directly involved with the encoding process. Silverlight authors should verify that the media they are using has alternate audio tracks encoded in it. If such tracks exist, Silverlight authors will need a track listing from the media producer to know which of the audio tracks is intended as the alternate audio. Other tracks might exist in the encoded media that provide language translations of the default audio, or that serve other purposes.

事例

事例 1: Changing AudioStreamIndex

This example has a UI definition in XAML and interaction logic in C#. In addition to the typical Play/Pause/Stop controls, this interface includes a Play Full-Description Audio button. Activating the button invokes a function that swaps the audio channels and plays an alternative synchronized audio channel that contains a composite full-description audio track.

The following is the basic UI in XAML. This example is deliberately simple and does not include AutomationProperties. Audio streams are identified by an index in a collection.

      <Grid x:Name="LayoutRoot" Background="White">
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="*" />
            <ColumnDefinition Width="*" />
            <ColumnDefinition Width="*"/>
        </Grid.ColumnDefinitions>
        <Grid.RowDefinitions>
            <RowDefinition Height="*" />
            <RowDefinition Height="Auto" />
            <RowDefinition Height="20" />
        </Grid.RowDefinitions>
        <MediaElement x:Name="media" Source="/combined.wmv"
           Width="300" Height="300" 
           Grid.Column="0" Grid.Row="0" Grid.ColumnSpan="3"
           AutoPlay="false"
        />
        <Button Click="StopMedia" 
     Grid.Column="0" Grid.Row="1" Content="Stop" />
        <Button Click="PauseMedia" 
     Grid.Column="1" Grid.Row="1" Content="Pause" />
        <Button Click="PlayMedia" 
     Grid.Column="2" Grid.Row="1" Content="Play" />
        <Button Name="AltAudioBtn" Grid.Row="2" HorizontalAlignment="Left" Grid.ColumnSpan="2" 
        Click="AltAudioBtn_Click">Play Full-Description Audio</Button>
    </Grid>

The following is the C# logic.

        private void AltAudioBtn_Click(object sender, RoutedEventArgs e)
        {
            if (media.AudioStreamCount > 1)
            {
                if (media.AudioStreamIndex == 1)
                {
                    media.AudioStreamIndex = 0;
                    (sender as Button).Content = "Play full-description audio";
                } else {
                    media.AudioStreamIndex = 1;
                   (sender as Button).Content = "Play default audio";
                }
            }
            else
            {
                (sender as Control).IsEnabled = false;
            }
        }
        private void StopMedia(object sender, RoutedEventArgs e)
        {
            media.Stop();
        }
        private void PauseMedia(object sender, RoutedEventArgs e)
        {
            media.Pause();
        }
        private void PlayMedia(object sender, RoutedEventArgs e)
        {
            media.Play();
        }

This example is shown in operation in the working example of Alternative Audio Channel. If using the test file, the test contains test audio tones rather than actual audio description, but the pitch of the tones is indicative of which of the channels is selected and played.

参考リソース

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

検証

手順

Open the HTML page for a Silverlight application, where that application plays media and the media is expected to support an alternate audio track for the video.
Verify that the application user interface presents a control that enables the user to cause the media to play with an alternate audio track.
Activate that control. Verify that the audio portion of the media player output as played through the computer's audio system is now playing the alternate audio track.

期待される結果

#2 and #3 are true.

SL2: Changing The Visual Focus Indicator in Silverlight

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.7 (フォーカスの可視化)
- クイックリファレンス 2.4.7 (フォーカスの可視化)
- 達成基準 2.4.7 (フォーカスの可視化)を理解する

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

SL2 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to use the Silverlight "control skinning" scenario and feature set to change the visible focus indication of a control. In particular, the intent is to increase the visibility of focus indication versus the appearance of a default-styled control. This technique is useful both for the control sets that are included in the Silverlight run time or SDK assemblies, as well as for Toolkit or any third party distributed control.

The default Silverlight core controls all indicate some type of visible focus indication, through their default templates. However, Silverlight application authors can still use the skinning techniques to augment or replace the visible focus indications for controls as used in their applications. For more information on how Silverlight controls will generally supply a default visual focus indicator, see Focus Overview on MSDN.

Silverlight control skinning is enabled through a deliberate separation of UI and logic in the Silverlight control model. Appearance of a control is largely written in XAML. The logic is largely written in code (for example C#) and is left unaffected when a Silverlight application author provides a new control template "skin". The hooks that connect the appearance and the logic are a Style property of the control (which the author changes the value of, to refer to their new XAML resource) and a contract of expected named entities in the XAML. The control logic invokes the names of the entities/parts whenever control state changes, and the expectation is that the named part provides the necessary appearance as defined in XAML. Design tools such as Visual Studio or Expression Blend generate copies of the default templates and parts, such that Silverlight authors can modify the parts that they want to change the appearance of, and still preserve the remainder of default appearance and behavior of the control.

For the visible focus indicator technique, the author typically modifies a single visual element that renders in layout as an overlay on top of the control when it is focused, and switches the overlay to nonvisible when the control is not focused. This element is a named element that is typically referred to from within the XAML named state Focused, which in turn is hooked up to changes in the visual state.

Note that this technique assumes that the original control author provided the necessary logic event hookup, and exposed a named state associated with keyboard focus to work with. If this is not the case, or if the scenario is that a Silverlight author is defining their own control, a different technique is needed. See SL7: Designing a Focused Visual State for Custom Silverlight Controls.

Focus in Silverlight

Focus in Silverlight is equivalent to the larger user interface and application concept of keyboard focus. The element that has focus is the element within the Silverlight object tree and programming model that has first chance to process the Silverlight key events. As a more tangible example that is user-centric, if a TextBox has keyboard focus, then when the user presses keys on the keyboard, the characters associated with the user's pressed keys will appear in the TextBox. A user interface element in Silverlight can obtain keyboard focus in one of three ways:

The user uses the Silverlight tab sequence to traverse into the Silverlight content and to focus a specific control.
The Silverlight application's logic calls the Focus method programmatically to force focus to a control.
The user performs some other action, for example uses the mouse to click on a control. That control's specific logic handles the Silverlight input event and uses that event as stimulus to call Focus on that control. The difference between this case and the above case is that the behavior is typically built-in to that control's runtime behavior, and does not require each application author to call Focus in application code.

事例

事例 1: Two Button elements, one reskinned to provide new visible focus indicator

XAML templates can be verbose; for clarity, only the parts of the template that were changed or useful for showing the structure are shown. Omitted portions are shown as ellipsis (...).

<UserControl x:Class="VisibleFocusTemplate.MainPage"
 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
 <UserControl.Resources>
   <Style x:Key="StrongFocusIndicator" TargetType="Button">
...
     <Setter Property="Template">
       <Setter.Value>
         <ControlTemplate TargetType="Button">
...
             <VisualStateManager.VisualStateGroups>
               <VisualStateGroup x:Name="FocusStates">
                 <VisualState x:Name="Focused">
                   <Storyboard>
                     <DoubleAnimation Duration="0" To="1"
 Storyboard.TargetProperty="Opacity"
 Storyboard.TargetName="FocusVisualElement"/>
                     <DoubleAnimation Duration="0" To="0.5"
 Storyboard.TargetProperty="(UIElement.Opacity)"
 Storyboard.TargetName="rectangle" d:IsOptimized="True"/>
                   </Storyboard>
                 </VisualState>
                 <VisualState x:Name="Unfocused"/>
               </VisualStateGroup>
             </VisualStateManager.VisualStateGroups>
...
             <Border x:Name="FocusVisualElement"
 IsHitTestVisible="false" Opacity="0"
 CornerRadius="2" BorderBrush="#D0FF0000"
 BorderThickness="4">
               <Rectangle x:Name="rectangle"
 IsHitTestVisible="false" Margin="2"
 Opacity="0" RadiusY="2" RadiusX="2"
 Fill="#A0FF0000"/>
             </Border>
          </ControlTemplate>
       </Setter.Value>
     </Setter>
   </Style>
 </UserControl.Resources>
 <StackPanel x:Name="LayoutRoot">
   <Button Width="275">Default button</Button>
   <Button Width="275"
 Style="{StaticResource StrongFocusIndicator}"
 >Button with re-templated focus visible indicator</Button>
 </StackPanel>
</UserControl>

The most interesting aspect of this example is the change made to the FocusVisualElement part. Here is the original (default template) FocusVisualElement:

<Rectangle x:Name="FocusVisualElement" RadiusX="2" RadiusY="2" Margin="1" Stroke="#FF6DBDD1" StrokeThickness="1" 
 Opacity="0" IsHitTestVisible="false" />

Here is the changed FocusVisualElement:

<Border x:Name="FocusVisualElement" IsHitTestVisible="false"
 Opacity="0" CornerRadius="2"
 BorderBrush="#D0FF0000" BorderThickness="4">
 <Rectangle x:Name="rectangle" IsHitTestVisible="false"
 Margin="2" Opacity="0"
 RadiusY="2" RadiusX="2" Fill="#A0FF0000"/>
</Border>

The following images show how each of the two buttons (default and reskinned) appear when focused.

Default button focus

Reskinned button focus

This example is shown in operation in the working example of Visible Focus Template.

参考リソース

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

SCR31: フォーカスのある要素の背景色又はボーダーを変更するために、スクリプトを使用する

検証

手順

Note that not all Silverlight applications necessarily will start with the keyboard focus being somewhere within the Silverlight content area for purpose of Step #2. It may be necessary to press TAB several times to traverse the browser's framing user interface. Also, within the browser's display area that displays the HTML document, there might also be other HTML elements that are keyboard focusable, which are representative of HTML that falls lexically before the <object> tag that instantiates the Silverlight plug-in. So it may also be necessary to press TAB several times until these HTML elements are traversed.

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
Using a keyboard, tab to the element where focus characteristics are being examined.
Check that the background, border, or other noticable visual indicator of the element changes color.
Check that the changes in color for the background, border, or other noticable visual indicator are removed when the element loses focus.

期待される結果

#3 and #4 are true.

SL3: Controlling Silverlight MediaElement Audio Volume

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.2 (音声の制御)
- クイックリファレンス 1.4.2 (音声の制御)
- 達成基準 1.4.2 (音声の制御)を理解する

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

SL3 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to adjust the volume for media that is played in Silverlight applications, as implemented through incorporating the Silverlight MediaElement object. By default, a MediaElement will start playing its media as soon as the UI loads completely AND the media source file is downloaded. For details, see SL24: Using AutoPlay to Keep Silverlight Media from Playing Automatically.

At any given time, a Silverlight MediaElement is associated with exactly one media source as specified by the Source property URI value. That source might be audio-only, or audio-video. The Volume property of MediaElement affects the audio playback volume of that particular source when it is playing. The Silverlight plug-in does not have a user option that adjusts the volume of ALL Silverlight applications as run within it, or a standardized user interface that is always present for all uses of MediaElement. Therefore it is the responsibility of Silverlight application authors to provide an adequate set of user interface controls, including volume adjustment, whenever the Silverlight application plays media that has an audio component.

事例

事例 1: Providing a volume control and a Mute control as part of a set of user interface controls that go with a MediaElement

In addition to the Play Pause Stop controls, application authors can also provide a dedicated control that changes the Volume property of the MediaElement. The typical control for setting a discrete volume is Slider, because Slider is designed for input of discrete values from a range. Adjusting Volume with a data bound Slider changes the volume of any actively playing media, independent of the system volume or of any other audio source controlled by Silverlight. For Volume as set with the Slider, the Binding in XAML declares the interaction between the control and the MediaElement, without requiring an event handler. However, not all users will be able to interact quickly with a Slider, particularly if they are not using a mouse. To help these users, application authors should also include a "Mute" control. Rather than setting Volume to 0, application authors should instead set IsMuted to true. Note that Volume and IsMuted values are not directly related; if IsMuted is set to true, that does not set Volume to 0, nor does setting Volume to zero cause IsMuted to be set true.

<UserControl x:Class="MediaElementControls.MainPage"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  >
   <Grid x:Name="LayoutRoot">
       <StackPanel>
           <MediaElement x:Name="media" Source="/xbox.wmv"
          Width="300" Height="300" 
          AutomationProperties.Name="Video of new Fable game for XBox"           
       />
           <Grid Name="UIControls">
               <Grid.ColumnDefinitions>
                   <ColumnDefinition Width="*" />
                   <ColumnDefinition Width="*" />
                   <ColumnDefinition Width="*"/>
               </Grid.ColumnDefinitions>
               <Grid.RowDefinitions>
                   <RowDefinition Height="*" />
                   <RowDefinition Height="Auto" />
                   <RowDefinition Height="20" />
               </Grid.RowDefinitions>
               <Button Click="StopMedia" 
    Grid.Column="0" Grid.Row="1" Content="Stop" />
               <Button Click="PauseMedia" 
    Grid.Column="1" Grid.Row="1" Content="Pause" />
               <Button Click="PlayMedia" 
    Grid.Column="2" Grid.Row="1" Content="Play" />
               <Button Click="MuteMedia" 
   Grid.Row="2" Grid.Column="0" Content="Mute" />
               <TextBlock Name="VolumeLabel" Grid.Row="2" Grid.Column="1" HorizontalAlignment="Right">Volume</TextBlock>
               <Slider Height="20"
           Value="{Binding Volume, Mode=TwoWay, ElementName=media}"
           Minimum="0" Maximum="1"
           Grid.Row="2" Grid.Column="2" Grid.ColumnSpan="2"
               AutomationProperties.LabeledBy="{Binding ElementName=VolumeLabel}"/>
           </Grid>
       </StackPanel>
   </Grid>
</UserControl>

The following is the C# logic.

 private void StopMedia(object sender, RoutedEventArgs e)
 {
     media.Stop();
 }
 private void PauseMedia(object sender, RoutedEventArgs e)
 {
     media.Pause();
 }
 private void PlayMedia(object sender, RoutedEventArgs e)
 {
     media.Play();
 }
 private void MuteMedia(object sender, RoutedEventArgs e)
 {
    Button target = sender as Button;
    // mute if not muted, unmute if already muted, in either case make sure the button content for text and accessibility info is updated
    if (!media.IsMuted)
    {
       media.IsMuted = true;
       target.Content = "Unmute";
    }
    else
    {
        media.IsMuted = false;
        target.Content = "Mute";
    }
 }

This example is shown in operation in the working example of Media Element Controls.

参考リソース

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

Volume
Audio and Video Overview
Silverlight Media Framework - a framework and a media player control implementation that incorporates many of the Silverlight techniques related to MediaElement

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. It is expected that the application incorporates a MediaElement.
Check that a control is available for controlling volume and that the Volume control controls the volume of the playing media, independently from system volume.
Check that control is available for muting, and that the Mute control mutes the volume of the playing media, independently from system volume.

期待される結果

#2 OR #3 is true.

SL4: Declaring Discrete Silverlight Objects to Specify Language Parts in the HTML DOM

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.2 (一部分の言語)
- クイックリファレンス 3.1.2 (一部分の言語)
- 達成基準 3.1.2 (一部分の言語)を理解する

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

SL4 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is use the HTML Lang attribute on the object tag to describe each Silverlight plug-in instance on the HTML hosting page as a "part" that has a different language. Assistive technologies that use HTML Lang as a determinant of language of parts can thus treat all Silverlight content as using that HTML Lang-declared language.

Most assistive technologies that are capable of determining Language for Web content will use the HTML Lang tag value as the determinant of the language of the page. Assistive technologies would also use HTML Lang tag values for the language of parts. HTML Lang is not specifically reported in accessibility frameworks. Assistive technologies would typically access the HTML DOM to get this information. This technique specifically addresses this known situation regarding how ATs obtain Language information from HTML rather than from accessibility frameworks that otherwise report other aspects of HTML content.

In order to support different language parts that each contain Silverlight content, authors declare one Silverlight object tag per continuous language part region in the HTML. For example, the following HTML is a simplication of HTML markup for a page that contains two Silverlight content areas, the first declaring Lang as English (en), the second declaring Lang as German (de):

     <body>
       <object type="application/x-silverlight-2" lang="en">
       </object>
       <object type="application/x-silverlight-2" lang="de">
       </object>
     </body>

To support communication between different Silverlight plug-in instances that are hosted on the same HTML page, application authors can use various techniques, including the following

System.Windows.Messaging APIs: this is the simplest technique, and this is shown in Example 1
Using a shared business object, and exchanging information by having each Silverlight instance reference two-way data binding to that business object's properties.
Exchanging information through the HTML DOM and declaring properties of one or both instances as Scriptable by the DOM.

Silverlight runtime language determination

Regardless of how HTML Lang is declared on the defining object tags, many aspects of how Silverlight works with language and culture information at run time are not determined by HTML Lang, and are instead determined by the operating system and which culture that operating system is running. For more information, see Understanding Language/Culture Properties as Used by Silverlight Applications and Assistive Technologies.

事例

事例 1: Two Silverlight object tags, each with different HTML Lang, to support a simple language-translator application as a Web page

The Visual Studio solution for this example has a total of 4 project components:

The Web project that declares the HTML or ASP page that shows the framework of how the two Silverlight object tags exist on a page. This is where the HTML Lang is actually set.
A project for the English user control, a simple TextBox.
A project for a German user control, also a simple TextBox.
A library with a static translation function

In this example, the English user control implements a LocalMessageSender, which sends asynchronous messages to the German user control. The German user control has a LocalMessageReceiver, which is set to listen as soon as the control is instantiated. When a message is received, the German control calls a function of the translation library, and displays translated text.

The following is the HTML page (some infrastructure and parameters omitted for clarity):

<html xmlns="http://www.w3.org/1999/xhtml" >
<body>

    <object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="25px" lang="en">
      <param name="source" value="ClientBin/SilverFish.xap"/>
    </object>

    <object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="25px" lang="de">
      <param name="source" value="ClientBin/SilverFish_DE.xap"/>
    </object>

</body>
</html>

The following is the XAML for the English user control:

<UserControl x:Class="SilverFish.MainPage"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Height="20" 
>
   <Grid x:Name="LayoutRoot" Background="White">
       <TextBox AcceptsReturn="False" Language="en-us"
       Name="EnglishTranslationBox" 
       LostFocus="EnglishTranslationBox_LostFocus"/>
   </Grid>
</UserControl>

The following is the code-behind for the English user control:

   public partial class MainPage : UserControl
   {
       private LocalMessageSender messagesender;
       public MainPage()
       {
           InitializeComponent();
       }
       private void EnglishTranslationBox_LostFocus(object sender, RoutedEventArgs e)
       {
           messagesender = new LocalMessageSender("receiver");
           messagesender.SendAsync((sender as TextBox).Text);
       }
   }

The following is the code-behind for the German user control (the XAML is minimal; the main relevant point is that it contains a TextBox target named GermanTranslationBox). The code invokes the translation function found in a separate library. The translation function is not shown, it simply takes an English string and returns a German translation.

   public partial class MainPage : UserControl
   {
       public MainPage()
       {
           InitializeComponent();
           LocalMessageReceiver lmr = new LocalMessageReceiver("receiver");
           lmr.MessageReceived += new EventHandler<MessageReceivedEventArgs>(lmr_MessageReceived);
           try
           {
               lmr.Listen();
           }
           catch (ListenFailedException) {}
       }
       void lmr_MessageReceived(object sender, MessageReceivedEventArgs e)
       {
           if (e.Message!="") {
               String translated;
               translated = Translator.TranslateThat(e.Message);
               GermanTranslationBox.Text = translated;
               GermanTranslationBox.Focus();
           }
       }
   }

This example is shown in operation in the working example of SilverFish.

参考リソース

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

検証

手順

Using a browser that supports Silverlight, open an HTML page that references multiple Silverlight object tags, each with different HTML Lang values.
Verify that language settings through HTML Lang on object tags are respected by assistive technologies that can use HTML Lang values for language of parts determination.

期待される結果

#2 gives expected results.

SL5: Defining a Focusable Image Class for Silverlight

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

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

SL5 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to wrap the Silverlight Image class inside a UI container class that is focusable. If the image is focusable, users who use the TAB sequence to navigate content while the assistive technology is active, and/or assistive technologies that construct navigation structures that are based on the TAB sequence, can both detect the image in navigation. The assistive technology can then associate alternative text for that image within the navigation structure, and report the information to the user.

Many existing assistive technologies do not construct initial navigation views that are derived from UI Automation information if it is coming from a non-focusable element in a Silverlight user interface. This is particularly true if the assistive technology is in a navigation mode that is specifically intended to help users enter information into a form or similar interactive interface element; an example of this situation is the Forms Mode of the JAWS screen reader.

Image is an example of a Silverlight element that is not focusable. This technique and the example therein are intended to circumvent the possible omission of a nonfocusable Silverlight Image element from certain navigation views in existing assistive technology implementations. The Silverlight Image is wrapped with a display/viewer control class that is focusable. This image-wrapping control is initially presented in assistive technology representations of a Silverlight user interface that use only focusable elements when constructing the assistive technology's representation of the application.

The image wrapper class uses the AutomationProperties.Name property to provide a short text alternative for the contained Image, so that the alternative text can be read or otherwise presented by assistive technologies. The Silverlight API AutomationProperties.Name directly sets Name in the UI Automation tree. The properties in the UI Automation tree are reported to assistive technologies, when the assistive technology implements behavior that acts as a UI Automation client. Name is one of the accessibility framework properties that most assistive technologies present in some way, for purposes of both name and value information, and setting Name is the common technique for exposing text alternatives for any other Control class (for example, for a button with an image, as shown in the technique SL18: Providing Text Equivalent for Nontext Silverlight Controls With AutomationProperties.Name).

This technique is intended for cases where application authors deliberately do not want a visible image caption for the image to be part of the user interface, and the image is a part of a larger interactive user interface control or page. Otherwise, if there is a visible caption, authors can use SL26: Using LabeledBy to Associate Labels and Targets in Silverlight.

事例

The two examples are intended to be used together, if an application is both defining and consuming the focusable image control.

事例 1: Defining the FocusableImage XAML template and C# code behavior

Silverlight supports a control development model whereby the visual appearance of a control is largely defined in XAML, and the behavior of a control (such as its event handling and hookups to services) are implemented in a managed code language such as C#. The following is the XAML template, which includes a visual state that shows visually when the control is focused in UI.

<ResourceDictionary
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:ImageEquivalent">
 <Style TargetType="local:FocusableImage">
   <Setter Property="Template">
    <Setter.Value>
      <ControlTemplate TargetType="local:FocusableImage">
        <Grid>
          <VisualStateManager.VisualStateGroups>
            <VisualStateGroup x:Name="FocusStates">
              <VisualState x:Name="Focused">
                <Storyboard>
                  <ColorAnimation  
 Storyboard.TargetName="focusborder"
 Storyboard.TargetProperty="(Border.BorderBrush).(SolidColorBrush.Color)"
 Duration="0" To="Blue"/>
                </Storyboard>
              </VisualState>
              <VisualState x:Name="Unfocused"/>
            </VisualStateGroup>
          </VisualStateManager.VisualStateGroups>
          <Border
            x:Name="focusborder"
            BorderThickness="4"
            BorderBrush="Transparent">
            <Image
             Margin="2" Opacity="10"
             Source="{TemplateBinding Source}"/>
         </Border>
       </Grid>
    </ControlTemplate>
    </Setter.Value>
   </Setter>
 </Style>
</ResourceDictionary>

The following is the C# class definition and logic. The logic includes invoking a default automation peer on creation, and loading the template as defined in the previous XAML example through the Silverlight "generic.xaml" resource convention for custom controls.

namespace ImageEquivalent
{
   public class FocusableImage : Control
   {
       protected override System.Windows.Automation.Peers.AutomationPeer OnCreateAutomationPeer()
       {
           return new FrameworkElementAutomationPeer(this);
       }
       public FocusableImage()
       {
           this.DefaultStyleKey = typeof(FocusableImage);
       }
       public ImageSource Source
       {
           get { return (ImageSource)this.GetValue(SourceProperty); }
           set { this.SetValue(SourceProperty,value); }
       }
       public static DependencyProperty SourceProperty = DependencyProperty.Register(
         "Source",
         typeof(ImageSource),
         typeof(FocusableImage),
         null);
       Boolean _Focused;
       void ChangeState()
       {
           if (_Focused)
           {
               VisualStateManager.GoToState(this,"Focused",false);
           }
           else
           {
               VisualStateManager.GoToState(this,"Unfocused",false);
           }
       }
       protected override void OnGotFocus(RoutedEventArgs e)
       {
           base.OnGotFocus(e);
           this._Focused = true;
           ChangeState();
       }
       protected override void OnLostFocus(RoutedEventArgs e)
       {
           base.OnGotFocus(e);
           this._Focused = false;
           ChangeState();
       }
   }
}

This example is shown in operation in the working example of Focusable Image.

事例 2: Using the FocusableImage class in UI and applying AutomationProperties.Name

Now that the image is wrapped by a focusable control, you can instantiate an instance of the wrapper UI inside a Silverlight layout container, specify AutomationProperties.Name at the level of the wrapper control’s tag, and have that text serve as the alternative text for the referenced source image file.

   <StackPanel
   xmlns:local="clr-namespace:ImageEquivalent;assembly=FocusableImage"
   >
   <local:FocusableImage
     Height="300" Width="400
     AutomationProperties.Name="Diagram of secret lair"
     Source="/diagram_lair.png" />
   </StackPanel>

参考リソース

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

H37: img 要素の alt 属性を使用する

検証

Automation Tree

手順

Open the test HTML page in a Silverlight-supported useragent host; to use UI Automation, use Microsoft Windows as platform.
Use the tab sequence inside the Silverlight content area to focus the control.
Using an accessibility framework verification tool, check that the string content is promoted as the default Name applied to the control.

注記: Accessibility framework verification tools typically show the entirety of an automation tree for a given application, and in fact will show the tree for all applications running on the Windows client machine. Focusing the control as in #2 is thus not strictly speaking necessary. However, manually focusing using the application interface is often a faster way to step into the automation tree as opposed to having to open an extensive series of nested nodes starting from the browser host application root. Whether this functionality exists depends on which accessibility framework verification tool is being used for testing.

期待される結果

#3 is true.

検証

Screen Reader

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. To use UI Automation, use Microsoft Windows as platform.
Engage the screen reader. Move focus to the control (for example, use the tab sequence).
Check that the Name applied to the image is read by the screen reader.

期待される結果

#3 is true.

SL6: Defining a UI Automation Peer for a Custom Silverlight Control

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- クイックリファレンス 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- 達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )を理解する

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

SL6 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to create an AutomationPeer class for a custom Silverlight control. The AutomationPeer exposes accessibility properties of the control in a way that abstracts the Silverlight technology specifics of the control model and maps information to UI Automation concepts, so that these properties can be consumed by the UI Automation accessibility framework.

The AutomationPeer concept is part of the overall architecture design of the UI Automation system. The peer represents a deliberate abstraction of the control, such that a client can obtain pattern-based information about the specific purpose and capability of a control without knowing its implementation-specific object model or having to resort to using a framework-specific object model API. Also, the peers run in a different process than the controls they represent, which has performance and security advantages. For more information on UI Automation architecture, see UI Automation Overview on MSDN.

Creating a custom Silverlight control is one way that Silverlight application authors can create user interface components either for their own application, or as a packaged redistributable that provides the control UI for third parties. Creating an automation peer for a custom control reports control-specific information to the UI Automation accessibility framework, and enables a custom control to participate in all of the same techniques involving UI Automation that can be used for a control that is distributed in the core Silverlight run time. Assistive technologies can use the UI Automation accessibility framework to discover the name and role of the user interface component, and can get and set values by accessing UI Automation patterns. UI Automation thus supports extensibility, while maintaining a discovery system for names, roles and values of UI components.

Control authors associate a peer with a class by implementing a method override for the class implementation. Control authors declare name and role through properties that are general to any UI Automation peer. Control authors expose the means to get and set values by choosing to support one or more patterns that are usually associated with a role. For example, a control in the role of "Button" would typically support an "Invoke" pattern. A consumer of UI Automation could check whether the pattern was supported and then call the pattern-based method Invoke, which would activate the button without any device input events being produced or required.

By convention, controls and their automation peers share a naming pattern. For example, if a control is named Spinner, its automation peer is named SpinnerPeer. However, the actual wiring for the class-peer association is made in the control code by overriding OnCreateAutomationPeer. Thus it is necessary to have access to the control code in order to associate a new peer class implementation with that control.

In addition to properties, automation peers can also expose methods as part of the implemented UI Automation control pattern. For example, a peer implementing the Value pattern can provide an implementation of the SetValue method. The SetValue method can be called by a UI Automation client in order to programmatically set the value of the owner control. The functionality exposed by the implementation of a control pattern can be accessed either by automation-based testing, or by assistive technologies.

事例

事例 1: SimpleNumericUpDown control and its peer

The example implements a very simple Silverlight custom control named SimpleNumericUpDown. The control is a templateable control, meaning that the UI is defined in a XAML file that serves as the default UI, but any consumer of the control can change the visual appearance by applying a new template. Nevertheless, the basic accessibility characteristics of the control can be shaped by the control author, and can apply even for cases where the visible UI is noticably different. This separation between design-implementation and code-behavior is one reason for the peer-owner design in UI Automation. The majority of the example shows the C# code, including the following :

Associating the peer with the class.
Defining the peer, and basic information such as the class name.
Reporting which patterns the peer supports. In this case the peer supports a Value pattern.

Control definition class:

   public class SimpleNumericUpDown : Control
   {
       public SimpleNumericUpDown()
       {
           this.DefaultStyleKey = typeof(SimpleNumericUpDown);
       protected override System.Windows.Automation.Peers.AutomationPeer OnCreateAutomationPeer()
       {
           return new SimpleNumericUpDownAutomationPeer(this);
       }
 // templating and event handlers omitted
       public static DependencyProperty NumericValueProperty = DependencyProperty.Register(
           "NumericValue",
           typeof(Int32),
           typeof(SimpleNumericUpDown),
           new PropertyMetadata(0)
           );
       public Int32 NumericValue
       {
           get { return (Int32)this.GetValue(NumericValueProperty); }
           set {this.SetValue(NumericValueProperty,value);}
       }
   }

Automation peer definition:

   public class SimpleNumericUpDownAutomationPeer : FrameworkElementAutomationPeer, IValueProvider
   {
       private SimpleNumericUpDown OwnerControl { get { return (SimpleNumericUpDown)Owner; } }
       public SimpleNumericUpDownAutomationPeer(SimpleNumericUpDown owner)
           : base(owner) {}
       //peer overrides
       protected override string GetClassNameCore()
       {
           return "SimpleNumericUpDown";
       }
       protected override AutomationControlType GetAutomationControlTypeCore()
       {
           return AutomationControlType.Spinner;
       }
       public override object GetPattern(PatternInterface patternInterface) {
           if (patternInterface == PatternInterface.Value)
           {
               return this;
           }
           return base.GetPattern(patternInterface);
       }
       // Value pattern implementation
       String IValueProvider.Value
       {
           get { return OwnerControl.NumericValue.ToString(); }
       }
       bool IValueProvider.IsReadOnly {get{return false;}}
       void IValueProvider.SetValue(string value)
       {
           OwnerControl.NumericValue = Convert.ToInt32(value);
       }

This example is shown in operation in the working example of Simple Numeric UpDown control.

参考リソース

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

G10: 名前 (name) 及び役割 (role) を取得し、利用者が設定可能なプロパティを直接設定可能にし、変化を通知するためにユーザエージェントが動作する、プラットフォームのアクセシビリティ API 機能をサポートするウェブコンテンツ技術を用いて、コンポーネントを作成する

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. To see UI Automation, use Microsoft Windows as platform.
Use a verification tool that is capable of showing the full automation tree, and an object’s UI Automation properties and patterns as part of the tree. (For example, use UIAVerify or Silverlight Spy; see Resources links.) Select the item in the automation tree that is accessing the relevant custom automation peer implementation.
Examine the set of properties exposed in the tree. Check that name is reported by Name, that the class name is reported as ClassName, and that there is a role as reported by the value of ControlType.
If the control is expected to report a value, check that the value is reported in the tree somehow. (Exactly which property reports the value varies depending on the control function and pattern; for more information, see Windows Automation API).
Check whether a control pattern is reported in the tree. If a control pattern is reported, test the methods of that pattern using facilities in the verification tool. Verify that invoking the methods has changed the corresponding read only property values in the tree.

期待される結果

#3, #4, and #5 (if applicable) are true.

SL7: Designing a Focused Visual State for Custom Silverlight Controls

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.7 (フォーカスの可視化)
- クイックリファレンス 2.4.7 (フォーカスの可視化)
- 達成基準 2.4.7 (フォーカスの可視化)を理解する

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

SL7 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to build custom visual states for custom controls that include visible focus indicators in the templates and parts.

The default Silverlight core controls all indicate some type of visible focus indication, through their default templates. For more information on how Silverlight controls will generally supply a default visual focus indicator, see Focus Overview on MSDN.

Silverlight control skinning is enabled through a deliberate separation of visible user interface design and control logic in the Silverlight control model. Control authors expect that application authors might reskin their control. But control authors should provide an initial default set of states, templates, etc. so that application authors have a good baseline of functionality to compare with their customization. Defining visible focus states for all control parts is an example of such baseline functionality. In order to make the visual focus state customizable, the visual state should be associated with a name. Ideally that name should have a human-readable meaning that hints at its purpose, but the real reason for the name is that it connects the XAML-defined template (which control consumers can change) with the control logic defined by the control author (which control consumers cannot change). Also, the visual names and groups in the XAML should be attributed on the control class, to assist design tools. The best resource for general information about Silverlight control customization is Silverlight documentation on MSDN.

Component Parts

Some controls are created by assembling various component parts that are already defined as controls either by the Silverlight run time libraries or by third parties. That scenario is not really what this technique is about, because in that case the focus behavior is already defined by the component's template, and the control author can re-use that behavior as-is or reskin it but still through the same named state definition. This technique specifically addresses how to define a control where the interactive surface has mouse and keyboard handling defined at a lower level for the control as a whole. The actual focus region is defined by the control author in that case, and the focus indicator is also defined to match the behavior visually and functionally.

Design for Focus Indicators

The general design principles for visual focus indicators are that the indicators should apply a visual change to the focus region's exterior margin. A common pattern is to deliberately define the visuals for the control with a pre-existing blank margin for its layout slot; that way when the focus indicator is applied, the focus indicator can fill that margin.

The actual graphic for the visual focus indicator is typically a border or shaped frame of a solid color brush with at least 1 pixel line thickness. The color used for the border stands out visually from the underlying control background or other elements of the control. The contrast between brush for visual focus and the remainder of control should be a contrast difference that is visible to users who do not distinguish the hue of colors, but can distinguish the lightness/value. In many cases the border is rectangular, to go along with the control's layout slot. However, if the control's basic shape is a non-rectangular shape, sometimes the focus indicator is designed to make a border around that shape. An example of a default Silverlight control that is round and applies an exterior round border as a focus indicator is a RadioButton.

Most focus indicator designs change only the border and do not change the main area of the control. One reason for this is that changes to the main control are typically reserved for other interactive states that also have a visual indicator. Specifically, controls need a visual state that indicates that the mouse is over the control (this is termed either MouseOver or Hover state). Controls that support activation also have a visual state that provides feedback for activation. For example, the default Silverlight RepeatButton changes its Background gradient on the button field to be darker blue value when the mouse is over the button, and changes to an even darker value blue when the button is activated (either by clicking the mouse or by pressing SPACE or ENTER with keyboard focus on the RepeatButton). To see this behavior in a live sample, see RepeatButton sample on MSDN.

Logic for Focus Indicators

Typical logic is that the border to indicate focus is present in the default template design, but with an initial value of Visibility=Collapsed. Then, a visual state for focus is defined with a name that properly indicates its purpose as text (example: "Focused"). In addition, a state is needed that undoes whatever changes were applied for focus, once focus moves to another element (for example, "Unfocused"). For example, if the "Focused" state sets the value Visibility=Visible on some element, the "Unfocused" state sets that value to Collapsed again. Silverlight's visual state system also provides a way to group related states with a factoring name (for example, "FocusStates"). For more information on state names and state groups in Silverlight visual states, as well as learning how these states define a control contract that any control consumers should follow if they reskin that control, see Customizing the Appearance of an Existing Control by Using a ControlTemplate on MSDN.

The visual state system is designed to support visual transitions to states, and for that reason the visual state system is closely coupled with the Silverlight animation system. By animating the transition, the visual appearance changes over a time interval. Typically, if transitions are used, the time interval is short, one second or less. In the case of focus indicators, it is typical to not use transitions and to instead make a discrete change; otherwise, the state change might be interpreted by users as a lag in interface response from their system.

The states themselves are designed in XAML, but are loaded and unloaded through logic that the control author defines as part of their control code. The control author does this by handling the appropriate events that occur while the event scope applies to their control. For example, to apply the "Focused" state, the control author handles the GotFocus event. Rather than handle the event directly, the more common pattern is to override a virtual method that acts as a prewired event handler, OnGotFocus. The centralized logic for visual state changes is the method GoToState, with one of the parameters to pass representing the XAML name of the correct state to load from the XAML templates. Examples for all of the APIs discussed here are available in the MSDN topic Creating a New Control by Creating a ControlTemplate.

Focus in Silverlight

Focus in Silverlight is equivalent to the larger user interface and application concept of keyboard focus. The element that has focus is the element within the Silverlight object tree and programming model that has first chance to process the Silverlight key events. As a more tangible example that is user-centric, if a TextBox has keyboard focus, then when the user presses keys on the keyboard, the characters associated with the user's pressed keys (or possibly input that is enabled by an assistive technology that can substitute for key strokes) will appear in the TextBox. A user interface element in Silverlight can obtain keyboard focus in one of three ways:

The user uses the Silverlight tab sequence to traverse into the Silverlight content and to focus a specific control.
The Silverlight application's logic calls the Focus() method programmatically to force focus to a control.
The user performs some other action, for example uses the mouse to click on a control. That control's specific logic handles the Silverlight input event and uses that event as stimulus to call Focus() on that control. The difference between this case and the above case is that the behavior is typically built-in to that control's runtime behavior, and does not require each application author to call Focus() in application code.

事例

事例 1: Visible focus indicator as a style and state

The following is the XAML that defines the basic (normal) control template. This control is simple: it has a yellow circle graphic, which overlays a red circle edge when the control is focused. The circle edge is defined by the "FocusVisual" element in the composition, and is initially Visibility=Collapsed (the expected visual state prior to being focused).

<ResourceDictionary
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   xmlns:local="clr-namespace:FocusVisualCustomControl"
>
   <Style TargetType="local:SampleControl">
       <Setter Property="Template">
           <Setter.Value>
               <ControlTemplate TargetType="local:SampleControl">
                   <Grid x:Name="ControlRoot">
                       <Ellipse x:Name="CoinGraphic"
                         Fill="Orange"
                         Width="{TemplateBinding Width}"
                         Height="{TemplateBinding Height}"
                       />
                       <Ellipse x:Name="FocusVisual"
                         Visibility="Collapsed"
                         Stroke="Red"
                         StrokeThickness="1"
                         Width="{TemplateBinding FrameworkElement.Width}"
                         Height="{TemplateBinding FrameworkElement.Height}"
                       />
                   </Grid>
               </ControlTemplate>
           </Setter.Value>
       </Setter>
   </Style>
</ResourceDictionary>

The following is the specific visual state portion. Note how the visual state includes an ObjectAnimation with discrete keyframes for hard transition between Visible and Collapsed, targeting the element "FocusVisual" in the composition shown in the previous XAML.

                       <VisualStateManager.VisualStateGroups>
                           <VisualStateGroup x:Name="FocusStates">
                               <VisualState x:Name="Unfocused"/>
                               <VisualState x:Name="Focused">
                                   <Storyboard>
                                       <ObjectAnimationUsingKeyFrames
                                         Storyboard.TargetName="FocusVisual" 
                                         Storyboard.TargetProperty="Visibility" Duration="0">
                                           <DiscreteObjectKeyFrame KeyTime="0">
                                               <DiscreteObjectKeyFrame.Value>
                                                   <Visibility>Visible</Visibility>
                                               </DiscreteObjectKeyFrame.Value>
                                           </DiscreteObjectKeyFrame>
                                       </ObjectAnimationUsingKeyFrames>
                                   </Storyboard>
                               </VisualState>
                           </VisualStateGroup>
                       </VisualStateManager.VisualStateGroups>

The following is control logic in the control class that responds to the focus-related events and switches visual states in response. In this particular example, "Unfocused" is a state without a definition. Switching to the definitionless state has the effect of reverting to the default state, which in the case of this design is intentional. Alternatively, authors could make specific template changes that revert any animation that applied to the focused state.

       protected override void OnGotFocus(RoutedEventArgs e)
       {
           base.OnGotFocus(e);
           VisualStateManager.GoToState(this, "Focused", false);
       }
       protected override void OnLostFocus(RoutedEventArgs e)
       {
           base.OnLostFocus(e);
           VisualStateManager.GoToState(this, "Unfocused", false);
       }

This example is shown in operation in the working example of Visual Focus Indicator.

参考リソース

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

SCR31: フォーカスのある要素の背景色又はボーダーを変更するために、スクリプトを使用する

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
Using a keyboard, tab to the element where focus characteristics are being examined.
Check that the background, border, or other noticable visual indicator of the element changes color.
Check that the changes in color for the background, border, or other noticable visual indicator are removed when the element loses focus.

期待される結果

#3 and #4 are true.

SL8: Displaying HelpText in Silverlight User Interfaces

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

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

SL8 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to provide a long text alternative that replaces content when a short text alternative is not sufficient for a given user, and the user specifically requests that the application should provide more context or more information through the application user interface. The technique could also apply for providing a long text alternative for a nontext object, for example for an image that contains a level of detail that is difficult to capture in a standard visible-in-UI image caption.

Silverlight supports a UI Automation property named HelpText, to connote its possible usage to provide imperative instructions for interactive elements. HelpText is not always forwarded to users by existing assistive technologies, which is an issue discussed in the technique SL19: Providing User Instructions With AutomationProperties.HelpText in Silverlight. Rather than relying on a particular assistive technology's support for enabling users to access the UIA HelpText, application authors can introduce user interface elements into their design that databind directly to the HelpText property, but where the interface element is not necessarily displayed by default. An interface update might be designed to occur if the application user specifically activates a "Get Help" action that is presented in the initial user interface.

This technique emphasises a "HelpText" model as a factoring practice. Silverlight application authors can use the HelpText as a data source that centralizes such information, because it already exists and has that intended purpose in accessibility frameworks. For example, the HelpText could be shown in a tooltip, a popup, a separate user interface element that is deliberately rendered in close proximity, etc. For accessibility support, a recommended display option for HelpText is to add or dynamically alter a Silverlight text element in the primary user interface. Silverlight supports an adaptive layout metaphor. Adding text to the runtime elements in the application generally causes an interface redraw, which in turn informs assistive technologies (through UIA properties and events) that content might have changed.

To set the UIA HelpText in Silverlight, you set the attached property AutomationProperties.HelpText. AutomationProperties.HelpText can be set in code, but is typically set in XAML that defines a Silverlight UI.

事例

事例 1: Displaying a long text alternative for an Image with XAML

Application authors can specify the AutomationProperties.HelpText attribute on the Image element. The value provided for the attribute should be a meaningful long text alternative for the image content. The value of AutomationProperties.HelpText should augment rather than duplicate any AutomationProperties.Name or an associated Label or LabeledBy caption. One or both of these is also typically specified to provide the basic (short-text) accessibility support for an image.

<StackPanel x:Name="imgContainer">
 <Image
   Height="400" Width="600"
   Source="/office.png"
   x:Name="imgOffice"
   AutomationProperties.HelpText=”The standard office layout
includes one corner desk unit in the corner farthest from the
door, and one file cabinet against the same wall as the door.”/>
 <sdk:Label x:Name="lblimgOffice" Target="{Binding ElementName=imgOffice}">Diagram of standard office layout</sdk:Label>
 <Button x:Name="HelpButton" Click="HelpButton_Click">Provide text-only alternative description of the previous image</Button>
</StackPanel>

The following event handler removes the Help button and replaces it in UI with a TextBox that displays the long text alternative.

       private void HelpButton_Click(object sender, RoutedEventArgs e)
       {
           imgContainer.Children.Remove(HelpButton);
           TextBox tb = new TextBox();
           tb.IsReadOnly=true;
           tb.Text = AutomationProperties.GetHelpText(imgOffice);
           imgContainer.Children.Add(tb);
           tb.Focus();
       }

事例 2: Using HelpText to augment existing form labels, to provide long text instructions

This example provides instructions for two form fields. The same text is also displayed for mouse users as a Tooltip and the AutomationProperties.HelpText string is used as a common source for both display options. In this example, the form submission does not perform client-side validation (although server-side validation following a data round trip might still exist, or validation could be added similar to the technique shown in SL35: Using the Validation and ValidationSummary APIs to Implement Client Side Forms Validation in Silverlight).

The following is the XAML UI:

<UserControl xmlns:sdk="http://schemas.microsoft.com/winfx/2006/xaml/presentation/sdk" 
   x:Class="HelpTextAndToolTip.MainPage"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
       <Grid x:Name="LayoutRoot" Background="White" Margin="10">
           <Grid.RowDefinitions>
               <RowDefinition Height="Auto"/>
               <RowDefinition Height="Auto"/>
               <RowDefinition Height="Auto"/>
               <RowDefinition Height="Auto"/>
               <RowDefinition Height="Auto"/>
           </Grid.RowDefinitions>
           <Grid.ColumnDefinitions>
               <ColumnDefinition Width="Auto"/>
               <ColumnDefinition Width="200"/>
               <ColumnDefinition Width="Auto"/>
           </Grid.ColumnDefinitions>
           <TextBlock Text="Form With Tooltips" FontSize="16" FontWeight="Bold"
     Grid.Column="1" HorizontalAlignment="Center" />
           <sdk:Label x:Name="NameLabel" Target="{Binding ElementName=NameTextBox}"
     Grid.Row="2" Margin="3"/>
           <TextBox x:Name="NameTextBox" 
     AutomationProperties.Name="{Binding Content, ElementName=NameLabel}"
     Text="{Binding Name, Mode=TwoWay, UpdateSourceTrigger=Explicit}"
     Grid.Column="1" Grid.Row="2" Margin="3"
                    AutomationProperties.HelpText="{Binding NameTextBoxToolTipString,Source={StaticResource TooltipStrings}}">
           <ToolTipService.ToolTip>
               <ToolTip Content="{Binding NameTextBoxToolTipString,Source={StaticResource TooltipStrings}}" />
           </ToolTipService.ToolTip>
           </TextBox>
           <sdk:Label x:Name="AgeLabel" Target="{Binding ElementName=AgeTextBox}"
     Grid.Row="3" Margin="3" HorizontalAlignment="Right"/>
           <TextBox x:Name="AgeTextBox" 
     AutomationProperties.Name="{Binding Content, ElementName=AgeLabel}" 
     Text="{Binding Age, Mode=TwoWay, UpdateSourceTrigger=Explicit}"  
     Grid.Column="1" Grid.Row="3" Margin="3"
    AutomationProperties.HelpText="{Binding AgeTextBoxToolTipString,Source={StaticResource TooltipStrings}}">
           <ToolTipService.ToolTip>
               <ToolTip Content="{Binding AgeTextBoxToolTipString,Source={StaticResource TooltipStrings}}" />
           </ToolTipService.ToolTip>
       </TextBox>
       <StackPanel Orientation="Horizontal">
           <Button x:Name="SubmitButton" Content="Submit" Click="SubmitButton_Click" Grid.Column="1" Grid.Row="4" Width="50" Margin="3" />
           <Button x:Name="HelpButton" Click="HelpButton_Click">Get Help</Button>
       </StackPanel>
       </Grid>
</UserControl>

The following is the resource definition in app.xaml:

       <ResourceDictionary>
           <resources:Resource1 x:Key="TooltipStrings"/>
       </ResourceDictionary>

NameTextBoxToolTipString: Must be 10 characters or less. Required.
AgeTextBoxToolTipString Must be a value between 0 and 120. Required.

The following is the event handler code, which changes the interface.

       private void HelpButton_Click(object sender, RoutedEventArgs e)
       {
           AgeLabel.Content = AgeLabel.Content + ": " + AutomationProperties.GetHelpText(AgeTextBox);
           NameLabel.Content = NameLabel.Content + ": " + AutomationProperties.GetHelpText(NameTextBox);
           NameTextBox.Focus();
       }

Note the call to Focus() - this puts the screen reader focus on the first form element so that the added text can be read. The very same text source as used for the Tooltip is added programmatically to the existing Label controls.

After the Get Help button is clicked, the visual appearance of the application is modified:

Before activating Get Help

Image:BeforeTooltipForm.png

After activating Get Help

Image:AfterTooltipForm.png

This example is shown in operation in the working example of HelpText and Tooltip.

参考リソース

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

SL19: Providing User Instructions With AutomationProperties.HelpText in Silverlight

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. To see UI Automation, use Microsoft Windows as platform.
For a control where this technique is used to provide a long text alternative, verify that an identifiable and usable "Get Help" control is present in the initial user interface or assistive technology representation of that interface.
Verify that activating the "Get Help" control changes the user interface, and the changed user interface now displays or reports long text alternatives that better address the user's information needs.
If using a screen reader, verify that the long text alternative can be read aloud.

期待される結果

#2 and #3 are true. If testing with a screen reader, #4 is true.

SL9: Handling Key Events to Enable Keyboard Functionality in Silverlight

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

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

SL9 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to handle key events in a Silverlight application and enable application-specific keyboard functionality in a Silverlight application. The keyboard functionality might relate to a particular element of the Silverlight application user interface, or might be a handler for global key events within the application, such as an application-wide access key.

In Silverlight, application authors handle user input by attaching event handlers for input events. The input events are implemented on a class that is a base element in the Silverlight class hierarchy, such that all Silverlight UI elements can be the source of an input event if the user interacts with them. Typically, the event handler names are specified in XAML, although it is also possible to wire events in code. The implementation of the handlers for the Silverlight managed code programming model is always done in C# or Visual Basic code.

The most commonly used input events are the following:

KeyUp, KeyDown - these are the key events. Which key is pressed is determined by event parameters passed to the handler.
MouseEnter, MouseOver, MouseLeave
MouseLeftButtonDown, MouseLeftButtonUp, MouseRightButtonDown, MouseRightButtonUp

Other forms of input that Silverlight supports include touch devices (with mouse promotion for cases where the application runs on devices that do not have touch input modes) and a related inking mode. For any UI interaction that uses mouse input or these other input modes, Silverlight application authors can write a parallel key event handler to provide users the keyboard equivalent.

Also, the Silverlight event system and control model combine to enable behavior whereby a mouse event and a keyboard event can be treated as the same event and can be handled by a common event handler. Using this technique, Silverlight authors can facilitate keyboard functionality in custom controls or as override behavior to existing Silverlight-supplied controls, and provide equivalence for mouse events or events that are specific to other input devices. Silverlight authors can also use controls that already have a keyboard equivalence as a built-in behavior.

The parallel key event handler case, and the built-in behavior case, are each shown in one of the examples.

All input events report a specific source that is communicated to handler code as an event parameter, so that the application author can identify which element in their Silverlight UI was being interacted with, and the application can perform an action that is relevant to that user input. In the case of mouse events, the event source is the element that the mouse pointer is over at the time. In the case of key events, the event source is the element that has focus. The element that has focus is visually indicated so that the user knows which element they are interacting with (see SL2: Changing The Visual Focus Indicator in Silverlight). Assistive technologies often have parallel conventions whereby the user is made aware of which element is visually focused and is the current input scope presented by the assistive technology,

Silverlight core control built-in keyboard functionality

The following is a list of the Silverlight-supplied controls that have some level of key equivalence as a built-in behavior. In these cases, it is not necessary to add a specific Key event handler; you can handle the event and/or rely on the built-in key handling as listed.

Button (SPACE and ENTER) - raises Click event.
Other ButtonBase classes eg RepeatButton, HyperlinkButton (SPACE and ENTER) - raises Click event.
TextBox (ENTER, unless in a mode where the TextBox accepts multiple lines) - moves focus to next control, treated like a TAB
ListBox (various keys) - see OnKeyDown Method.
ComboBox (arrow keys ) - traverse list choices as control UI if popup area displayed.
RichTextBox (various keys ) - enable edit mode operations; see RichTextBox Overview.
Slider (arrow keys ) - increment/decrement values.

Browser hosts and keyboard events

Silverlight is hosted as a plug-in inside a browser host. The Silverlight run-time only receives the input events that the browser host forwards to hosted plug-ins through a browser-specific program access layer. Occasionally the browser host receives input that the browser host itself handles in some way, and does not forward the keyboard event. An example is that a Silverlight application hosted by an Internet Explorer browser host on Windows operating system cannot detect a press of the ALT key, because Internet Explorer processes this input and performs the action of bringing keyboard focus to the Internet Explorer menu bar. Silverlight authors might need to be aware of browser-specific input handling models and not rely on key events for keys that are essentially reserved for use by a browser host. For more information, see Keyboard Support.

Other event models

This technique specifically discusses event handling for the Silverlight managed programming model. However, Silverlight also supports parallel models for event handling, either through a Silverlight run-time feature or due to Silverlight's role as a plug-in within a script-capable browser host. For example, events from the HTML DOM can be handled by JavaScript at HTML scope for the overall Silverlight plug-in; this uses the browser host as script processor and the Silverlight run-time is not directly involved. Or, HTML DOM events can be handled through an HTML bridge that calls into Silverlight application code. These event models can potentially be used to provide keyboard equivalence, but it is generally more convenient to use the managed code model as described in this technique. For more information on other event models in Silverlight, see Events Overview for Silverlight.

事例

Two examples are given. The first example is for the scenario of a Silverlight application author that is simply incorporating an existing control into their application design, and is taking advantage of mouse-keyboard equivalence that is already defined by certain Silverlight core controls. The second example is from the perspective of a control author, or at least that of a Silverlight application author that intends to encapsulate behavior in a custom Silverlight control and use it in their own application. For this second example, the control will handle the general Silverlight input event KeyUp, in order to check for input from key(s) that are designated to have a specific input meaning for that control.

事例 1: Built-in keyboard equivalence for core Silverlight controls

This example pertains to cases where the control that handles key events is focusable (through the tab sequence, etc.) and where an existing Silverlight control behavior provides the keyboard equivalence In this example, a Silverlight UI includes a Button element. For sighted users, or users that generally use the mouse to interact with UI, a typical way to interact with the button is to position the mouse pointer over the element, and click the left mouse button. However, the Button also supports a built-in key handling behavior, whereby either the SPACE or ENTER keys are treated as an equivalent action to clicking the button with a mouse. The requirement for this interaction is that the Button must have keyboard focus at the point in time that SPACE or ENTER are pressed. The Button might gain focus because the user pressed the TAB key to move through the tab sequence, or some equivalent action enabled by assistive technology. In terms of the programming experience, the Silverlight application author does not have to separately handle KeyDown for this case. Within the Button control built-in code, the special case of SPACE or ENTER keys pressed while a Button has focus invokes the button’s Click event. Then the Silverlight application author can simply handle Click without differentiating whether the input action was a mouse click or a keyboard equivalent. The following is the entire XAML UI.

<UserControl x:Class="BuiltInKeyEquivalence.MainPage"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
   <Grid x:Name="LayoutRoot" Background="White" Loaded="LayoutRoot_Loaded">
       <Button Name="button1"
   AutomationProperties.Name="Equivalence test"
   Height="20" Width="150"
   Click="button1_Click">Click me, or press SPACE!</Button>
   </Grid>
</UserControl>

The following is the C# logic.

   private void button1_Click(object sender, RoutedEventArgs e)
   {
       MessageBox.Show("You clicked a button ... or maybe you hit the space bar ... or ENTER ... it's all the same to me.");
   }
   private void LayoutRoot_Loaded(object sender, RoutedEventArgs e)
   {
       System.Windows.Browser.HtmlPage.Plugin.Focus();
    }

This example is shown in operation in the working example of built-in keyboard equivalents.

事例 2: Keyboard events for a custom control, keyboard equivalence

In this example, a new Silverlight custom control named SimpleNumericUpDown uses a control template that includes two buttons. To provide keyboard equivalence for the buttons, an event handler is defined by the control class code. The event handler invokes the action in response to certain accelerator keys, where these actions are equivalent to clicking the button composition parts of the control with a mouse. The following is the default XAML template.

<ControlTemplate TargetType="local:SimpleNumericUpDown">
  <Border Background="{TemplateBinding Background}"
          BorderBrush="{TemplateBinding BorderBrush}"
          BorderThickness="{TemplateBinding BorderThickness}" Name="controlFrame">
      <Grid>
          <Grid.ColumnDefinitions>
              <ColumnDefinition Width="*"/>
              <ColumnDefinition Width="30"/>
          </Grid.ColumnDefinitions>
          <TextBox x:Name="valueBox" Text="{Binding NumericValue, RelativeSource={RelativeSource TemplatedParent}}"/>
          <StackPanel Grid.Column="1">
              <Button Name="minusButton">-</Button>
              <Button Name="plusButton">+</Button>
          </StackPanel>
      </Grid>
  </Border>
</ControlTemplate>

The following C# code shows the event handlers. Also, the code includes the event-wiring technique that is used whenever a Silverlight control author implements a templateable control. This technique enables the separation of UI appearance (which can be overridden) from the input event-handling behavior (which is implemented by the control author).

   public class SimpleNumericUpDown : Control
   {
       public SimpleNumericUpDown()
       {
           this.DefaultStyleKey = typeof(SimpleNumericUpDown);
       }
       
       public override void OnApplyTemplate()
       {
           base.OnApplyTemplate();
           Button plusButton = GetTemplateChild("plusButton") as Button;
           Button minusButton = GetTemplateChild("minusButton") as Button;
           Border controlFrame = GetTemplateChild("controlFrame") as Border;
           plusButton.Click += new RoutedEventHandler(Increment);
           minusButton.Click += new RoutedEventHandler(Decrement);
           controlFrame.KeyUp += new KeyEventHandler(Handle_Accelerators);
       }
       private void Increment(object sender, RoutedEventArgs e)
       {
           this.NumericValue += 1;
       }
       private void Decrement(object sender, RoutedEventArgs e)
       {
           this.NumericValue -= 1;
       }
       private void Handle_Accelerators(object sender, KeyEventArgs e)
       {
           switch (e.Key)
           {
               case (Key.Left):
                   this.NumericValue -= 1; 
                   e.Handled=true;
                   break;
               case (Key.Right):
                   this.NumericValue += 1; 
                   e.Handled=true;
                   break;
               default: break;
           }
       }
       public Int32 NumericValue //definition omitted in this example
   }

This example is shown in operation in the working example of custom keyboard events.

参考リソース

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

G90: キーボードがトリガーとなるイベントハンドラを提供する

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
Press TAB key to move keyboard focus to various element parts of the user interface.
Verify that any user interface actions that exist for a given element part each have a keyboard equivalent.

期待される結果

#3 is true.

SL10: Implementing a Submit-Form Pattern in Silverlight

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

達成基準 3.2.2 (入力時)
- クイックリファレンス 3.2.2 (入力時)
- 達成基準 3.2.2 (入力時)を理解する

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

SL10 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to declare Silverlight user interface elements related to user input and use the Silverlight two-way data binding techniques to provide a Submit button and opt-in forms submission logic pattern for forms. The Submit button serves as the final deliberate step of a form submission scenario. Silverlight programming techniques do not provide a "Submit button as a distinct object. Rather, application authors design their user input workflow such that it is a single user action that initiates change of context that is related to a data input scenario. The key to doing this in Silverlight is to use a data binding mode that sets UpdateSourceTrigger of all individual databound fields in that form or transaction. For any data binding where the UpdateSourceTrigger is Explicit, no real-time change is made to the data, until the UpdateSource method is called on each of these bindings. The application-specific Submit button is connected to an event handler that calls UpdateSource on all of the databound UI elements that comprise that form.

Validation of data

The Submit button itself can also be the UI element that provides warnings, instructions, etc. in a way that assistive technologies can report to users, through the AutomationProperties techniques. Using a Submit model for Silverlight form input to databound data sources relies on a particular data binding mode. The Submit model can be used either along with client-side or server-side validation techniques. The example does not explicitly include either validation technique.

事例

事例 1: Two form fields with Submit

In this example, the form fields correspond to a data object that implements a view model. Silverlight uses the view model and data annotations to generate some of its UI, notably the names of the fields are bound to the original view model names from the data. This example has a UI defined in XAML and logic defined in C#. The following is the XAML UI , which also includes the binding definitions. Note the Mode=TwoWay, UpdateSourceTrigger=Explicit attributes in the bindings. This is the binding mode to use for the Submit button scenario.

<UserControl x:Class="BasicSubmitButton.MainPage"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   xmlns:sdk="http://schemas.microsoft.com/winfx/2006/xaml/presentation/sdk">
 <StackPanel x:Name="LayoutRoot" Background="White" Margin="10">
   <Grid>
   <Grid.RowDefinitions>
       <RowDefinition Height="Auto"/>
       <RowDefinition Height="Auto"/>
       <RowDefinition Height="Auto"/>
       <RowDefinition Height="Auto"/>
       <RowDefinition Height="Auto"/>
   </Grid.RowDefinitions>
   <Grid.ColumnDefinitions>
       <ColumnDefinition Width="Auto"/>
       <ColumnDefinition Width="200"/>
       <ColumnDefinition Width="Auto"/>
   </Grid.ColumnDefinitions>
   <TextBlock Text="Form Input" FontSize="16" FontWeight="Bold"
     Grid.Column="1" HorizontalAlignment="Center" />
       <sdk:Label x:Name="NameLabel" Grid.Row="2" Margin="3"
   HorizontalAlignment="Right"
   Target="{Binding ElementName=NameTextBox}"/>
   <TextBox x:Name="NameTextBox" 
     AutomationProperties.Name="{Binding Content, ElementName=NameLabel}"
     Text="{Binding Name, Mode=TwoWay, UpdateSourceTrigger=Explicit}"
     Grid.Column="1" Grid.Row="2" Margin="3" />
       <sdk:Label x:Name="AgeLabel" Grid.Row="3" Margin="3"
   HorizontalAlignment="Right"
   Target="{Binding ElementName=AgeTextBox}"/>
   <TextBox x:Name="AgeTextBox" 
     AutomationProperties.Name="{Binding Content, ElementName=AgeLabel}" 
     Text="{Binding Age, Mode=TwoWay, UpdateSourceTrigger=Explicit}"  
     Grid.Column="1" Grid.Row="3" Margin="3" />
   <Button x:Name="SubmitButton" Content="Submit" Click="SubmitButton_Click"
     Grid.Column="1" Grid.Row="4" Width="50" Margin="3"
   AutomationProperties.HelpText="Activate this button to submit form."/>
   </Grid>
 </StackPanel>
</UserControl>

The following is the C# logic for the page. Note the SubmitButton_Click handler. This implementation disables the Submit button (representative of a change of context, because now the form cannot be submitted again) and provides user feedback without performing any validation. The test file included in this technique sets up its data object as a purely client side entity and does no validation, so that no service/server is necessary to use the test file. Each element with a binding calls the UpdateSource method, such that the act of pressing the Submit button commits all the form's information all at once. A full implementation might replace this with a server side data object infrastructure. A full implementation might also provide a "Reset" or "Edit" button to enable form submission again if there were issues.

private void SubmitButton_Click(object sender, RoutedEventArgs e)
{
   (sender as Button).IsEnabled = false;
   NameTextBox.GetBindingExpression(TextBox.TextProperty).UpdateSource();
   AgeTextBox.GetBindingExpression(TextBox.TextProperty).UpdateSource();
   TextBlock tb = new TextBlock();
   tb.Text="Thank you, your form information was submitted.";
   LayoutRoot.Children.Add(tb);
}

This example is shown in operation in the working example of Basic Submit Button.

参考リソース

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

Data Binding

G80: コンテキストの変化を開始する送信ボタンを提供する

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. To test UI Automation based behavior such as reading AutomationProperties.HelpText, use Microsoft Windows as platform.
Verify that the user interface design of the form includes a clearly indicated Submit button (a control that adequately communicates to users that activating it will cause input to be submitted and might cause a change of context).
Provide values for the various input fields of the form, and verify that doing so does not in and of itself change the context.
Verify that if change of context occurs at all, that action is delayed until after the Submit button is activated.

期待される結果

#2, #3, and #4 are true.

SL11: Pausing or Stopping A Decorative Silverlight Animation

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.2 (一時停止、停止、非表示)
- クイックリファレンス 2.2.2 (一時停止、停止、非表示)
- 達成基準 2.2.2 (一時停止、停止、非表示)を理解する

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

SL11 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to associate a "Pause" or "Stop" action for a Silverlight animation with a user interface control. This enables a user to pause or stop an animation in Silverlight content.

The Silverlight animation system is generalized such that nearly any Silverlight property of type Double, Point or Color can be animated, or a property can cycle through discrete object values. Thus the possibilities for which properties in the user interface can be animated are quite broad. The general technique shown can be used to pause or stop any Silverlight animation, including those that are purely decorative.

Pause versus Stop

Silverlight has two discrete methods for animation control: a Pause method and a Stop method. The difference in behavior is that Pause uses whatever the last value was while the animation was still running, and holds that value permanenently (unless the animation is restarted). Stop sets the value to be whatever value existed before the animation was started. However, calling Stop on an animation often results in a behavior that looks like a "reset" to the user; this is particularly true if the animation is animating an element's position on screen. In many cases, what might be a conceptual "stop" for the user is better accomplished by a "permanent Pause" in the Silverlight animation API. Whether to call Pause or Stop is an aesthetic decision and application authors can experiment to see which behavior has the best appearance. If application authors choose to use Stop, authors can simply replace the call to .Pause() with a call to .Stop() for any code that is based on this technique's example.

事例

事例 1: Pausing a decorative animation

The following is the XAML UI. The animated object and the animation behavior are both described in XAML, as is the control that users can activate to pause the animation.

<UserControl x:Class="PauseBouncyBall.MainPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
 <UserControl.Resources>
   <Storyboard x:Key="anim" RepeatBehavior="Forever" >
       <DoubleAnimationUsingKeyFrames Storyboard.TargetName="Ball"
          Storyboard.TargetProperty="(Canvas.Top)"
        FillBehavior="HoldEnd" AutoReverse="True">
               <EasingDoubleKeyFrame Value="100" KeyTime="00:00:01">
                   <EasingDoubleKeyFrame.EasingFunction>
                       <BounceEase Bounces="-1" EasingMode="EaseIn"/>
                   </EasingDoubleKeyFrame.EasingFunction>
               </EasingDoubleKeyFrame>
           </DoubleAnimationUsingKeyFrames>
   </Storyboard>
 </UserControl.Resources>
 <Canvas x:Name="LayoutRoot" Background="White" Height="600" Width="800">
   <Ellipse Name="Ball" Fill="Red" Width="20" Height="20" Canvas.Top="200">
       <Ellipse.RenderTransform>
           <TransformGroup>
               <TranslateTransform/>
           </TransformGroup>
       </Ellipse.RenderTransform>
   </Ellipse>
   <Button HorizontalAlignment="Left" Width="200" Click="Button_Click">Stop the bouncy ball please!</Button>
 </Canvas>
</UserControl>

The following is the C# logic. One function is the "page" constructor, which is what starts and loops the animation. The other function is the event handler for the UI control (a button). The event handler retrieves the animation definition from the page resources, and calls the Pause method on the animation.

       public MainPage()
       {
           InitializeComponent();
           (this.Resources["anim"] as Storyboard).Begin();
       }
       private void Button_Click(object sender, RoutedEventArgs e)
       {
           (this.Resources["anim"] as Storyboard).Pause();
       }

This example is shown in operation in the working example of Pause Bouncy Ball.

参考リソース

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

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. For Silverlight content with moving, blinking, scrolling or auto-updating content that is the result of a running Silverlight animation:
Check for a mechanism to stop the movement, blinking, scrolling or auto-updating.
Check that the movement, blinking, scrolling or auto-updating stops when the mechanism is activated and does not restart by itself.
For pause, check that the animation can be restarted using a start mechanism.

期待される結果

#3 is true.

SL12: Pausing, Stopping, or Playing Media in Silverlight MediaElements

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.2 (一時停止、停止、非表示)
- クイックリファレンス 2.2.2 (一時停止、停止、非表示)
- 達成基準 2.2.2 (一時停止、停止、非表示)を理解する

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

SL12 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to create a control user interface for the Silverlight MediaElement object. The controls enable users to pause or stop the video to prevent the video images on the MediaElement surface from moving, and stop video-associated audio. These UI controls enable an interaction defined in code event handlers. Each handler calls one of the following MediaElement methods:

Note that by default, a MediaElement will start playing its media as soon as the UI loads completely AND the media source file is downloaded (or a certain buffer size is reached, in the case of streaming media). Use the AutoPlay property to change this default.

事例

事例 1: Providing MediaElement controls in the UI

This example has a UI definition in XAML and interaction logic in C#.

<UserControl x:Class="MediaElementControls.MainPage"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 >
  <Grid x:Name="LayoutRoot">
      <StackPanel>
          <MediaElement x:Name="media" Source="/xbox.wmv"
         Width="300" Height="300" 
         AutomationProperties.Name="Video of new Fable game for XBox"           
      />
          <Grid Name="UIControls">
              <Grid.ColumnDefinitions>
                  <ColumnDefinition Width="*" />
                  <ColumnDefinition Width="*" />
                  <ColumnDefinition Width="*"/>
              </Grid.ColumnDefinitions>
              <Grid.RowDefinitions>
                  <RowDefinition Height="*" />
                  <RowDefinition Height="Auto" />
                  <RowDefinition Height="20" />
              </Grid.RowDefinitions>
              <Button Click="StopMedia" 
   Grid.Column="0" Grid.Row="1" Content="Stop" />
              <Button Click="PauseMedia" 
   Grid.Column="1" Grid.Row="1" Content="Pause" />
              <Button Click="PlayMedia" 
   Grid.Column="2" Grid.Row="1" Content="Play" />
              <Button Click="MuteMedia" 
  Grid.Row="2" Grid.Column="0" Content="Mute" />
              <TextBlock Name="VolumeLabel" Grid.Row="2" Grid.Column="1" HorizontalAlignment="Right">Volume</TextBlock>
              <Slider Height="20"
          Value="{Binding Volume, Mode=TwoWay, ElementName=media}"
          Minimum="0" Maximum="1"
          Grid.Row="2" Grid.Column="2" Grid.ColumnSpan="2"
              AutomationProperties.LabeledBy="{Binding ElementName=VolumeLabel}"/>
          </Grid>
      </StackPanel>
  </Grid>
</UserControl>

private void StopMedia(object sender, RoutedEventArgs e)
{
    media.Stop();
}
private void PauseMedia(object sender, RoutedEventArgs e)
{
    media.Pause();
}
private void PlayMedia(object sender, RoutedEventArgs e)
{
    media.Play();
}
private void MuteMedia(object sender, RoutedEventArgs e)
{
    Button target = sender as Button;
    // mute if not muted, unmute if already muted, in either case make sure the button content for text and accessibility info is updated
    if (!media.IsMuted)
    {
        media.IsMuted = true;
        target.Content = "Unmute";
    }
    else
    {
         media.IsMuted = false;
         target.Content = "Mute";
     }
}

This example is shown in operation in the working example of Media Element Controls.

参考リソース

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

Audio and Video Overview
MediaElement Class
Silverlight Media Framework - a framework and a media player control implementation that incorporates many of the Silverlight techniques related to MediaElement

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. The application is expected to incorporate a MediaElement in the user interface.
Check that interactive controls are available so that users can pause or stop the media.
Check that when activated, the controls stop or pause the media.

期待される結果

#2 and #3 are true.

SL13: Providing A Style Switcher To Switch To High Contrast

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

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

SL13 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to incorporate high contrast color choices into a user interface visual design for Silverlight, by changing the values of styles or templates, or changing values of individual resources such as brushes or colors.

Silverlight styles and templates are produced in XAML. Silverlight event handlers (such as the ones that engage the style switch) are written in code, but are often wired through a method name reference in the XAML. For more information on how to use templates, styles and resources to change the appearance of Silverlight controls, see Control Customization topic on MSDN.

Silverlight provides a built-in property that can determine whether the hosting operating system is using a high contrast theme. This is a Boolean value only; Silverlight API cannot determine any further specifics about the theme choice, such as the colors being used or the contrast ratio between the colors. Querying this property at application startup is one possible trigger mechanism for applying high contrast themes to Silverlight content. Another mechanism is to expose a control (such as a button or text link) to the user, so that the user can engage high contrast for a Silverlight application's content by activating a control within the Silverlight application.

Silverlight Toolkit themes and System Colors

An extension to the Silverlight core deliverables known as the Silverlight Toolkit provides theming APIs and various themed styles for Silverlight controls, including the core controls. Most of these themes are intended for design purposes, but the Silverlight Toolkit also provides a System Colors theme. The System Colors theme aligns the Silverlight theme brushes or colors with those of the settings applied to the Microsoft Windows operating system display options. When the user switches the system themes to use a theme that is typically used for high contrast, the underlying system brushes are redefined. A Silverlight application that uses the System Colors theme also uses the now-redefined colors in its UI, and will effectively use the same High Contrast colors that are user-selected for all other display. How to use the Silverlight Toolkit system themes is not described in this technique. However, the Silverlight Toolkit theme system is a viable option for providing high contrast as well as other more aesthetics-oriented UI experiences. For more information about the Silverlight Toolkit, see Toolkit site. The themes feature of Silverlight Toolkit is best explained by Silverlight Toolkit release notes (from a Microsoft-related blog).

Real-time changes not supported

SystemParameters.HighContrast is an adequate trigger for cases where high contrast is already engaged before the Silverlight plugin is loaded into a host. However, a limitation of using SystemParameters.HighContrast as a trigger mechanism is that Silverlight does not detect the change if it happens after the Silverlight plugin is loaded by the host HTML. If Silverlight authors want to support real-time changes, they should provide a user-initiated control option for changing to high contrast in Silverlight UI rather than solely relying on SystemParameters.HighContrast.

Silverlight and CSS

Silverlight content does not use information that comes from a CSS style as applied to the hosting HTML page. Therefore, techniques as implemented by browser user agents and described by G148: Not specifying background color, not specifying text color, and not using technology features that change those defaults or G156: Using a technology that has commonly-available user agents that can change the foreground and background of blocks of text do not work for Silverlight content, and C29 does not directly apply. For example, the Internet Explorer settings under Options / Appearance do not affect the fonts or contrast in the Silverlight content area.

事例

事例 1: Silverlight application designed with brush resources and template resources that enable a high contrast switch

The example "application" for illustration is just text, a button and border. The concepts shown in the example can scale to any complexity of UI, including to applications that have thousands of lines of XAML. Note that the visual appearance of the button is already using a high contrast theme choice for its default state, to assure that the control is visible to anyone that requires a high contrast theme to see parts of the user interface per G174. To keep the example simple, the visual states (behaviors) associated with mouse-over, click, etc. have not been restyled for high contrast. Only the base appearance is changed. The example also shows a technique of storing original theme information and restoring it in response to user request.

<UserControl x:Class="HighContrast.MainPage"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
   xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
   mc:Ignorable="d"
   d:DesignHeight="300" d:DesignWidth="400">
   <UserControl.Resources>
       <SolidColorBrush x:Key="ArtsyBrush1" Color="Salmon"/>
       <SolidColorBrush x:Key="ArtsyBrush2" Color="Bisque"/>
       <SolidColorBrush x:Key="ArtsyBrush3" Color="DarkSalmon"/>
       <SolidColorBrush x:Key="ArtsyBrush4" Color="Blue"/>
       <Color x:Key="ArtsyBrush1Restore">Salmon</Color>
       <Color x:Key="ArtsyBrush2Restore">Bisque</Color>
       <Color x:Key="ArtsyBrush3Restore">DarkSalmon</Color>
       <Color x:Key="ArtsyBrush4Restore">Blue</Color>
       <RadialGradientBrush x:Key="ArtsyGradient">
           <GradientStop Color="AliceBlue" Offset="0"/>
           <GradientStop Color="LightBlue" Offset="0.4"/>
           <GradientStop Color="#D00000EE" Offset="1"/>
       </RadialGradientBrush>
       <Style x:Key="ArtsyButton" TargetType="Button">
           <Setter Property="Template">
               <Setter.Value>
                   <ControlTemplate TargetType="Button">
                       <Border CornerRadius="4"
                          BorderBrush="{StaticResource ArtsyBrush4}" BorderThickness="4">
                           <Grid>
                               <Rectangle Fill="{StaticResource ArtsyGradient}"
                                 RadiusX="2" RadiusY="2"/>
                               <ContentPresenter Content="{TemplateBinding Content}"
                               ContentTemplate="{TemplateBinding ContentTemplate}"/>
                           </Grid>
                           
                       </Border>
                   </ControlTemplate>
               </Setter.Value>
           </Setter>
       </Style>
       <Style x:Key="HighConButton" TargetType="Button">
           <Setter Property="Control.Background" Value="White"/>
           <Setter Property="BorderBrush" Value="Black"/>
           <Setter Property="Foreground" Value="Black"/>
       </Style>
   </UserControl.Resources>
   <Border BorderBrush="{StaticResource ArtsyBrush1}" BorderThickness="4">
       <StackPanel x:Name="LayoutRoot" Background="{StaticResource ArtsyBrush2}">
           <TextBlock
             Foreground="{StaticResource ArtsyBrush3}">High contrast demo</TextBlock>
           <Button Name="Switcher" Click="Switcher_Click"
             Width="160" Style="{StaticResource HighConButton}">
              <TextBlock Text="Switch to high contrast"/>
           </Button>
           <Button Name="Switchback" Click="Switchback_Click"
             Width="160" Style="{StaticResource HighConButton}" IsEnabled="False">
               <TextBlock Text="Switch to regular theme"/>
           </Button>
       </StackPanel>
   </Border>
</UserControl>

The second listing is the C# code for the event handlers.

       private void Switcher_Click(object sender, RoutedEventArgs e)
       {
           ChangeToHighCon();
       }
       private void ChangeToHighCon()
       {
           (this.Resources["ArtsyBrush1"] as SolidColorBrush).Color = Colors.Black;
           (this.Resources["ArtsyBrush2"] as SolidColorBrush).Color = Colors.White;
           (this.Resources["ArtsyBrush3"] as SolidColorBrush).Color = Colors.Black;
           (this.Resources["ArtsyBrush4"] as SolidColorBrush).Color = Colors.Black;
           Switcher.IsEnabled = false;
           Switchback.IsEnabled = true;
       }
       private void RestoreRegularCon()
       {
           (this.Resources["ArtsyBrush1"] as SolidColorBrush).Color =
             (Color)this.Resources["ArtsyBrush1Restore"];
           (this.Resources["ArtsyBrush2"] as SolidColorBrush).Color =
             (Color)this.Resources["ArtsyBrush2Restore"];
           (this.Resources["ArtsyBrush3"] as SolidColorBrush).Color =
           (Color)this.Resources["ArtsyBrush3Restore"];
           (this.Resources["ArtsyBrush4"] as SolidColorBrush).Color =
             (Color)this.Resources["ArtsyBrush4Restore"];
           Switcher.IsEnabled = true;
           Switchback.IsEnabled = false;
       }
       private void Switchback_Click(object sender, RoutedEventArgs e)
       {
           RestoreRegularCon();
       }
   }

The following images show the original, and the applied high contrast settings.

Low contrast image with "switch to high contrast" button enabled

High contrast image with "switch to regular theme" button enabled

This example is shown in operation in the working example of High Contrast.

事例 2: Use SystemParameters.HighContrast to detect system high contrast settings at application startup

This example uses the same UI and style definitions as the previous example. The sole addition a case statement that is added to the primary page constructor of the UI (defined in C#). The added code is everything other than the InitializeComponent() call (which is part of Silverlight infrastructure). Note that the added code calls a user-defined function ChangeToHighCon(), which is the same function and behavior as shown in Example 1 for the user-initiated high contrast switch.

       public MainPage()
       {
           InitializeComponent();
           if (SystemParameters.HighContrast)
           {
               ChangeToHighCon();
           }
       }

参考リソース

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

G174: 利用者が十分なコントラストのある提示に切り替えられるように、十分なコントラスト比のあるコントロールを提供する

検証

UI option for style switching

手順

To test a Silverlight UI option for style switching (Example 1):

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
Check for a control that indicates it will change the application's appearance to use a high-contrast theme.
Activate the control. Check that the Silverlight application's user interface color themes change to an appearance that uses at least a 4.5:1 contrast ratio per Success Criterion 1.4.3 (Contrast (Minimum)).

期待される結果

#3 is true.

検証

HighContrast API

手順

To test the HighContrast API (Example 2):

Use operating system settings (such as Ctrl+LeftShift+PrtScn shortcut on Windows 7) to enter high contrast mode prior to opening the test page.
Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
Check that the Silverlight application's user interface color themes change to an appearance that uses at least a 4.5:1 contrast ratio per Success Criterion 1.4.3 (Contrast (Minimum)).

期待される結果

#3 is true.

検証

UI option for enhanced contrast

手順

To test a Silverlight UI option for style switching for enhanced contrast:

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
Check for a control that indicates it will change the application's appearance to use an enhanced contrast theme.
Activate the control. Check that the Silverlight application's user interface color themes change to an appearance that uses at least a 7:1 contrast ratio per Success Criterion 1.4.6 Contrast (Enhanced).

期待される結果

#3 is true.

SL14: Providing Custom Control Key Handling for Keyboard Functionality in Silverlight

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

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

SL14 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to implement built-in handling of key events in a custom control. If a custom control is correctly implemented, then any Silverlight applications that include the control can rely on the built-in key handling for some or all of the desired keyboard equivalence of a control's functionality.

Defining a custom control requires that the control author write a default template for the control and also the initialization logic, including the default implementations for built-in keyboard equivalence. Typically, control authors provide keyboard equivalence for any actions that can be activated by a mouse click on the control surface, and that are not already providing a keyboard equivalence through the implementation of a composite part.

Browser hosts and keyboard events

Silverlight is hosted as a plug-in inside a browser host. The Silverlight runtime only receives the input events that the browser host forwards to hosted plug-ins through a browser-specific program access layer. Occasionally the browser host receives input that the browser host itself handles in some way, and does not forward the keyboard event. An example is that a Silverlight application hosted by an Internet Explorer browser host on Windows operating system cannot detect a press of the ALT key, because Internet Explorer processes this input and performs the action of bringing keyboard focus to the Internet Explorer menu bar. Silverlight authors might need to be aware of browser-specific input handling models and not rely on key events for keys that are essentially reserved for use by a browser host. For more information, see Keyboard Support.

Application authors should choose keys that avoid browser conflicts, but still are a natural choice for an accelerator. Using the CTRL key as a modifier is a convention that is frequently used in existing Silverlight applications.

Informing users of which keys to use for keyboard equivalence

If a control supports user interaction, which key to use to engage the keyboard equivalent behavior is not always obvious. One way to inform users of the possible key options that a control supports is to author an AutomationProperties.HelpText value in the application UI that gives instructions such as "Press the plus key to increment value". This is up to the application author to do; the control definitions do not provide a means to set HelpText by default, because any display technique for end user help is potentially too application-specific to be encapsulated in control definitions. Application authors might also consider using tooltips, providing a menu framework that visually indicates the key associations (perhaps with the Windows key-underlined convention), providing a generalized application Help, or displaying plain text in the user interface.

The On* method pattern in Silverlight

Silverlight classes often have methods that follow the naming pattern On* where the star is a string that also identifies an event. These On* methods are prewired event handlers, defined as virtual methods so that subclasses can override them. A consumer of a control class can change or augment the default behavior associated with that event by overriding the method, and typically also calls the base implementation so that the base functionality is preserved. This principle is illustrated in Example 1 by the overrides of OnGotFocus and OnLostFocus. Controls that introduce new events should consider also exposing a virtual On* method that pairs with the event, so that consumers of the custom control can use the same pattern.

事例

事例 1: KeyNumericUpDown Control That Handles Arrow Key Equivalence for + and - Buttons

This example implements a custom Silverlight control that displays an integer value, and can increment or decrement the integer value based on user actions. When a user interacts with the control, the user can click the "+" and "-" buttons that are component parts of the control. The "+" and "-" button parts are deliberately not in the Silverlight tab sequence, because this is intended to be a complete control, where only the control itself (and not its constituent parts) are focusable and are reported as an element to the accessibility framework. To provide keyboard equivalence, the control defines a KeyUp handler. The design of the control treats an Up Arrow key press as equivalent to activating the "+" button, and the Down Arrow key as equivalent to activating the "-" button. The control implementation reinforces this behavior by having the button Click event handlers and the cases of the KeyUp handler call the same underlying helper functions (Increment() and Decrement()).

Handling the + and - keys as alternate or additional keyboard equivalents for the actions is also possible (if that is desired, handler would check for Key.Add or Key.Subtract values).

The following is the XAML-defined control template for this control.

   <Style TargetType="local:KeysNumericUpDown">
       <Setter Property="BorderThickness" Value="1"/>
       <Setter Property="Height" Value="22"/>
       <Setter Property="BorderBrush">
           <Setter.Value>
               <LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0">
                   <GradientStop Color="#FFA3AEB9" Offset="0"/>
                   <GradientStop Color="#FF8399A9" Offset="0.375"/>
                   <GradientStop Color="#FF718597" Offset="0.375"/>
                   <GradientStop Color="#FF617584" Offset="1"/>
               </LinearGradientBrush>
           </Setter.Value>
       </Setter>
       <Setter Property="Template">
           <Setter.Value>
               <ControlTemplate TargetType="local:KeysNumericUpDown">
                   <Grid x:Name="CompositionRoot">
                       <Grid.ColumnDefinitions>
                           <ColumnDefinition/>
                           <ColumnDefinition/>
                       </Grid.ColumnDefinitions>
                       <TextBox x:Name="Text" IsTabStop="False" AcceptsReturn="False"
 BorderThickness="0" Foreground="{TemplateBinding Foreground}" FontWeight="{TemplateBinding FontWeight}"
 FontStyle="{TemplateBinding FontStyle}" FontStretch="{TemplateBinding FontStretch}"
 FontSize="{TemplateBinding FontSize}" FontFamily="{TemplateBinding FontFamily}" MinWidth="20"
 TextAlignment="Right" VerticalAlignment="Center"  TextWrapping="NoWrap" Text="{TemplateBinding Value}">
                               <TextBox.Style>
                                   <Style TargetType="TextBox">
                                       <Setter Property="Template">
                                           <Setter.Value>
                                               <ControlTemplate TargetType="TextBox">
                                                   <ScrollViewer x:Name="ContentElement" BorderThickness="0" Padding="0"/>
                                               </ControlTemplate>
                                           </Setter.Value>
                                       </Setter>
                                   </Style>
                               </TextBox.Style>
                           </TextBox>
                       <StackPanel Orientation="Vertical" Grid.Column="1">
                       <Button Width="18" Height="18" IsTabStop="False" x:Name="plusButton">+</Button>
                       <Button Width="18" Height="18" IsTabStop="False" x:Name="minusButton">-</Button>
                       </StackPanel>
                       <Border x:Name="FocusVisualElement" BorderBrush="#FF45D6FA" BorderThickness="{TemplateBinding BorderThickness}" 
                       CornerRadius="1,1,1,1" IsHitTestVisible="False" Opacity="0"/>
                   </Grid>
               </ControlTemplate>
           </Setter.Value>
       </Setter>
   </Style>

The following is the implementation of the control class. Overrides of the base class are omitted for clarity, as is automation support. Note the event wiring in OnApplyTemplate; this is a common pattern for custom control definitions.

   public class KeysNumericUpDown : UpDownBase<double>
   {
       Grid root;
       Button plusButton;
       Button minusButton;
       Border focusRect;
       public KeysNumericUpDown()
       {
           this.DefaultStyleKey = typeof(KeysNumericUpDown);
       }
       public override void OnApplyTemplate()
       {
           base.OnApplyTemplate();
           root = this.GetTemplateChild("CompositionRoot") as Grid;
           root.KeyUp += new KeyEventHandler(Handle_Accelerators);
           plusButton = this.GetTemplateChild("plusButton") as Button;
           minusButton = this.GetTemplateChild("minusButton") as Button;
           plusButton.Click += new RoutedEventHandler(plusButton_Click);
           minusButton.Click += new RoutedEventHandler(minusButton_Click);
           focusRect = this.GetTemplateChild("FocusVisualElement") as Border;
       }
       void plusButton_Click(object sender, EventArgs e)
       {
           Increment();
       }
       void minusButton_Click(object sender, EventArgs e)
       {
           Decrement();
       }
       private void Increment()
       {
           this.Value += 1;
       }
       private void Decrement()
       {
           this.Value -= 1;
       }
       private void Handle_Accelerators(object sender, KeyEventArgs e)
       {
           switch (e.Key)
           {
               case (Key.Up):
                   this.Value -= 1;
                   e.Handled = true;
                   break;
               case (Key.Down):
                   this.Value += 1;
                   e.Handled = true;
                   break;
               default: break;
           }
       }
       protected override void OnGotFocus(RoutedEventArgs e)
       {
           base.OnGotFocus(e);
           if (focusRect != null)
           {
               focusRect.Opacity = 1;
           }
       }
       protected override void OnLostFocus(RoutedEventArgs e)
       {
           base.OnLostFocus(e);
           focusRect.Opacity = 0;
       }
   }

When this control is included in application UI, the usage is very simple. Note that there are no key handlers on this instance; the necessary key handling to wire up the increment/decrement logic is already built-in to all instances of the control.

<local:KeysNumericUpDown Width="100" Height="45"/>

This example is shown in operation in the working example of Numeric Up / Down control.

参考リソース

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

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
Press TAB key to move keyboard focus to various element parts of the user interface, and in particular to areas that are known to be custom control implementations.
Check that custom key commands exist for all these user interface actions and that these key commands are made known to the user.

期待される結果

#3 is true.

SL15: Providing Keyboard Shortcuts that Work Across the Entire Silverlight Application

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

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

SL15 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to introduce key handling that exists at the application root level of a Silverlight application, rather than per-element key handling. Event handling at the application level as opposed to at the element level is one way to address key equivalence. The key events provide key equivalence for particular user interface elements that a user might otherwise interact with using a mouse. This technique is related to events in the Silverlight programming model, as opposed to in the HTML DOM.

Handling key events at the root level of an application rather than only on the element that was the "source" of a key event is possible because of a Silverlight programming model feature known as event routing. For more information on event routing and how it works, see Events Overview for Silverlight.

This technique demonstrates a "menu" approach to key handling and user interaction. This technique is presented as a companion to SL9: Handling Key Events to Enable Keyboard Functionality in Silverlight, which can be thought of as an "accelerator key/hotkey" approach. The "menu" approach towards keyboard equivalence is perhaps just as common as the "hotkey" approach. It is often simpler to document a menu's key equivalence in a user interface than it is to document key equivalents of particular regions of an application, or to communicate to users that where the current focus is placed is relevant to how keyboard keys are interpreted by the application, even if the key action is relevant to only one of the controls in an interface. If all keys are handled at the top level, the specific focused element is no longer relevant.

In order to originate a key event that Silverlight application code can detect, some element in the Silverlight application must have keyboard focus. One way to assure keyboard focus is to focus the Silverlight plug-in as a whole, as called from within an event handler for Application.Startup. This is shown in the examples.

If an application does handle keys at top level, care should be taken to not interfere with specific text entry control behavior, such as typing into a TextBox. To avoid interactions, the design of key equivalence at the top level of an application typically relies on combinations with key modifiers. The Control/CTRL key is a key that is often used for this purpose. Application authors should also be aware of the implications of browser hosts that might handle the key event at HTML DOM level without making that event available to the Silverlight programming surface. For more information on this concept, see "Keyboard Events and Browser Hosts" section of Keyboard Support Overview for Silverlight on MSDN.

Application authors are responsible for correctly documenting the accelerator keys that are pertinent for their application. There are a variety of techniques for documenting user interface actions that are not described here. One possible suggestion is to include a generalized "Help" button that appears early in the application's reading order, which is focusable and has an AutomationProperties.Name value available as the text content or equivalent. Such a button can be activated without knowing any of the application's accelerator keys, and the activation result could be a new text element that enumerates the possible keys. For example, the application could display a Silverlight Popup with the following content:

A screen shot of a sample Popup control that documents specific accelerator keys

事例

事例 1: Key handling by application root UserControl

This example has only one interactive control for simplicity, but with two possible key combinations for that control being handled as actions. The purpose and explanation of the control is reported through a TextBlock that is associated with the labeled control through use of AutomationProperties.LabeledBy in XAML. The control being illustrated is MultiScaleImage, which supports a zoom-in metaphor for examining an image that redraws at increasingly fine resolutions. For more information on MultiScaleImage, see Deep Zoom on MSDN.

The following is the startup logic at application level that sends focus to Silverlight in the HTML DOM.

       private void Application_Startup(object sender, StartupEventArgs e)
       {
           this.RootVisual = new MainPage();
           //bring overall DOM focus to Silverlight area, so that keys are captured by Silverlight
           System.Windows.Browser.HtmlPage.Plugin.Focus();
       }

The following is XAML UI for the main page.

 <UserControl xmlns:sdk="http://schemas.microsoft.com/winfx/2006/xaml/presentation/sdk"
    x:Class="ApplicationLevelKeyHandling.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400" KeyUp="UserControl_KeyUp">

    <StackPanel x:Name="LayoutRoot" Background="White">
        <Button Name="bInstructions" Click="bInstructions_Click">Get Help</Button>
        <Popup Name="p">
            <Grid>
                <Grid.RowDefinitions>
                    <RowDefinition/>
                    <RowDefinition/>
                    <RowDefinition/>
                    <RowDefinition/>
                </Grid.RowDefinitions>
                <Grid.ColumnDefinitions>
                    <ColumnDefinition/>
                    <ColumnDefinition/>
                </Grid.ColumnDefinitions>
                <TextBlock FontWeight="Bold">Key</TextBlock>
                <TextBlock FontWeight="Bold" Grid.Column="1">Action</TextBlock>
                <TextBlock Grid.Row="1">Ctrl + Alt + Plus</TextBlock>
                <TextBlock Grid.Row="1" Grid.Column="1">Zooms in on the image</TextBlock>
                <TextBlock Grid.Row="2">Ctrl + Alt + Minus</TextBlock>
                <TextBlock Grid.Row="2" Grid.Column="1">Zooms out of the image</TextBlock>
                <Button Grid.Row="3" Click="button1_Click">Close this Help</Button>
            </Grid>
        </Popup>
        <MultiScaleImage x:Name="deepZoomObject"
         Source="source/dzc_output.xml" 
         MouseLeftButtonDown="DeepZoomObject_MouseLeftButtonDown"
         MouseRightButtonDown="DeepZoomObject_MouseRightButtonDown"
         AutomationProperties.LabeledBy="{Binding ElementName=lblInstructions}"/>
    </StackPanel>
 </UserControl>

The following is the C# logic. Note how the key handlers and mouse handlers reference the same logic function.

        private void UserControl_KeyUp(object sender, KeyEventArgs e)
        {
            if ((Keyboard.Modifiers & ModifierKeys.Control) == ModifierKeys.Control &&
                (Keyboard.Modifiers & ModifierKeys.Alt) == ModifierKeys.Alt &&
                e.Key == Key.Add)
            {
                DZIn();
            }
            if ((Keyboard.Modifiers & ModifierKeys.Control) == ModifierKeys.Control &&
                (Keyboard.Modifiers & ModifierKeys.Alt) == ModifierKeys.Alt &&
                e.Key == Key.Subtract)
            {
                DZOut();
            }
        }
        private void DeepZoomObject_MouseLeftButtonDown(object sender, MouseButtonEventArgs e)
        {
            DZIn();
        }
        private void DeepZoomObject_MouseRightButtonDown(object sender, MouseButtonEventArgs e)
        {
            e.Handled = true;
            DZOut();
        }
        private void DZIn()
        {
            this.deepZoomObject.ZoomAboutLogicalPoint(3, .5, .5);
        }
        private void DZOut()
        {
            this.deepZoomObject.ZoomAboutLogicalPoint(.333, .5, .5);
        }
        private void bInstructions_Click(object sender, RoutedEventArgs e)
        {

            // Set where the popup will show up on the screen.
            p.VerticalOffset = 25;
            p.HorizontalOffset = 25;
            // Open the popup.
            p.IsOpen = true;
        }
        void button1_Click(object sender, RoutedEventArgs e)
        {
            // Close the popup.
            p.IsOpen = false;

        }

This example is shown in operation in the working example of Application Level Key Handling.

参考リソース

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

SL9: Handling Key Events to Enable Keyboard Functionality in Silverlight

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
Verify that keyboard focus is somewhere within the Silverlight content area, and not elsewhere in the hosting HTML or hosting browser user interface. If necessary, use TAB key to traverse the overall HTML tab sequence until an interface element within Silverlight displays a visual focus indicator.
Verify that the keys to be used as keyboard equivalent action triggers for the application as a whole are documented for users. For example, text or long text alternative documents key / key combinations and short descriptions of actions.
Verify that pressing the application-specific keys results in the action as expected in the application.
Move keyboard focus throughout other areas of the Silverlight application, and verify that the same keys continue to function application-wide.

期待される結果

#3, #4 and #5 are true.

SL16: Providing Script-Embedded Text Captions for MediaElement Content

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

達成基準 1.2.2 (キャプション (収録済) )
- クイックリファレンス 1.2.2 (キャプション (収録済) )
- 達成基準 1.2.2 (キャプション (収録済) )を理解する

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

SL16 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to use text captioning that is embedded in the stream with media displayed in a Silverlight MediaElement, and present that text captioning in a separate Silverlight control or text element.

This particular technique uses scripting files with a TimelineMarkers collection that are embedded directly within the media file. When text captioning is embedded directly in the streams, synchonization of the scripting stream versus the video content stream is done automatically by the MediaElement component. Each time the MarkerReached event fires, that is an indication that a synch point in the video that corresponds to a script marker entry has been reached. Silverlight application authors can obtain the text from the relevant timeline marker entry through their event handler implementations, and can display captions in the user interface area where the text captions are displayed. Typical Silverlight controls that can be used for displaying text captions include TextBlock (nonfocusable), TextBox, or RichTextBox. A typical interface design would place the caption-display control in close proximity to the MediaElement control that is being captioned, for example might place the captions directly underneath the MediaElement "screen".

Script-embedded captions are captions that are stored directly in the media file as metadata, rather than as a separate file. For information about techniques for captions in separate files, see SL28: Using Separate Text-Format Text Captions for MediaElement Content.

Tools

Producing the media file with TimelineMarkers captions directly in embedded scripting can be accomplished using the Microsoft Expression Encoder tool. Online help for the procedure of encoding scripting with text captions in the stream are available in the offline Help file that installs with the Microsoft Expression 4 Encoder products. For more information, see Expression Encoder Pro Overview.

There is a public API for introducing Markers into a WMV file, as part of the Windows Media Format SDK. Using Expression Encoder is the way that the task of directly embedding TimelineMarkers is presented and taught in Microsoft's available instructional material on Silverlight. However, because the mechanism is public, it is possible that other tools exist or will exist that can also produce media with script-encoded TimelineMarkers.

事例

事例 1: MediaElement handles MarkerReached, displays marker text in existing TextBox

This example has a UI definition in XAML and interaction logic in C#. The following is the basic UI in XAML. This example is deliberately simple and does not include AutomationProperties for identification or user instructions. The most relevant part of this example is that the Silverlight author declares a handler for the event MarkerReached. This event fires potentially hundreds of times, once for each caption in the stream. Each time the event fires, the event handler runs and adds the text to the dedicated TextBox in the user interface.

<UserControl x:Class="MediaTimelineMarkers.MainPage"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
   <StackPanel x:Name="LayoutRoot" Background="White">
       <MediaElement MarkerReached="OnMarkerReached"
       HorizontalAlignment="Left"
       Source="/spacetime.wmv"
       Width="300" Height="200" />
       <ScrollViewer>
           <TextBox Name="captionText" Height="40"
           IsReadOnly="true" AcceptsReturn="true"/>
       </ScrollViewer>
   </StackPanel>
 </UserControl>

private void OnMarkerReached(object sender, TimelineMarkerRoutedEventArgs e)
{
   captionText.Focus();
   captionText.SelectedText = e.Marker.Text.ToString() + "\n";
}

This example is shown in operation in the working example of Media Timeline Markers.

参考リソース

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

Audio and Video Overview
MediaElement Class
Accessible Media Project - a reference implementation MediaPlayer control from the Silverlight product team that includes several accessibility features including captioning; note that the codebase might not be updated to Silverlight version 4

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. The application plays media that is expected to have text captioning.
Check that a text area in the user interface shows captions for the media.

期待される結果

# 2 is true.

SL17: Providing Static Alternative Content for Silverlight Media Playing in a MediaElement

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

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

SL17 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to replace a Silverlight MediaElement with static alternative non-media content that is not time-based. The static alternative content replaces the media in the same or a nearby user interface region of the Silverlight application.

If the media being played is audio-only, and the alternative content is a text equivalent such as a transcript, this technique addresses Success Criterion 1.2.1 (Audio-only and Video-only, Prerecorded).
If the media includes content that cannot be adequately described by either alternative audio track or additional text captions, and the best alternative is to provide a full description in text such as a screenplay of the content, this technique addresses Success Criterion 1.2.3 (Audio Description or Full Text Alternative) and is similar to G69: Providing an alternative for time based media.

A Silverlight application user interface can be adjusted at run time by removing elements from the visual tree, and adding new elements to the visual tree. In this case, the user interface is designed to provide a control that the user activates to display the static alternative content, which is often a control that displays text, or a text element.

事例

事例 1: MediaElement playing audio, replace with transcript

This example has a UI definition in XAML and interaction logic in C#. In this case the MediaElement has no visual representation itself and is 0x0 size because it plays audio only. As a simple placeholder, this example displays the text "Library of Congress Audio" to represent the media element as something visible in the UI. In addition to Play/Stop controls, this interface includes a Display Transcript button. Activating the button displays static text that represents the transcript of the audio. The following is the basic UI in XAML.

<UserControl x:Class="ReplaceAudioWithTranscriptText.MainPage"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   xmlns:sys="clr-namespace:System;assembly=mscorlib">
   <UserControl.Resources>
       <sys:String x:Key="transSpeakerName">Matt Raymond: </sys:String>
       <sys:String x:Key="transText">This is Matt Raymond at the Library of Congress.
Each year thousands of book lovers of all ages visit the nation's capital to celebrate the joys 
of reading and lifelong literacy, at the Library of Congress National Book Festival. 
For the first time in the festival's nine year history, President Barack Obama and 
First Lady Michelle Obama will serve as honorary chairs of this free event. </sys:String>
   </UserControl.Resources>
   <StackPanel x:Name="LayoutRoot" Background="White" >
       <TextBlock FontSize="30" Foreground="Blue">Library of Congress Audio</TextBlock>
       <MediaElement Source="/locintro.wma" AutoPlay="False" Name="player" Height="0" />
       <StackPanel Orientation="Horizontal" Name="ControlBar">
           <Button Name="Play" Click="Play_Click">Play</Button>
           <Button Name="Stop" Click="Stop_Click">Stop</Button>
           <Button Name="TextAlt" Click="TextAlt_Click">Display Transcript</Button>
       </StackPanel>
   </StackPanel>
</UserControl>

The following is the C# logic.

   public partial class MainPage : UserControl
   {
       RichTextBox rtb;
       bool transDisplayed=false;
       public MainPage()
       {
           InitializeComponent();
           rtb = new RichTextBox();
           rtb.IsReadOnly = true;
           Paragraph p = new Paragraph();
           Run speakerName = new Run();
           speakerName.Text = this.Resources["transSpeakerName"] as String;
           speakerName.FontWeight = FontWeights.Bold;
           Run transText = new Run();
           transText.Text = this.Resources["transText"] as String;
           p.Inlines.Add(speakerName);
           p.Inlines.Add(transText);
           rtb.Blocks.Add(p);
       }
       private void Play_Click(object sender, RoutedEventArgs e)
       {
           player.Play();
           Play.IsEnabled = false;
       }
       private void Stop_Click(object sender, RoutedEventArgs e)
       {
           player.Stop();
           Play.IsEnabled = true;
       }
       private void TextAlt_Click(object sender, RoutedEventArgs e)
       {
           Panel parent = (player.Parent as Panel);
           if (!transDisplayed)
           {
               DisplayTranscript();
               (sender as Button).Content = "Hide Transcript";
               transDisplayed = true;
           }
           else
           {
               parent.Children.Remove(rtb);
               (sender as Button).Content = "Display Transcript";
               transDisplayed = false;
           }
       }
       private void DisplayTranscript()
       {
           Panel parent = (player.Parent as Panel);
           parent.Children.Add(rtb);
       }

This example is shown in operation in the working example of Replace Audio With Transcript.

参考リソース

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

Audio and Video Overview

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. That application has audio-only media content and is expected to supply a text alternative, or has media that is expected to be replaced entirely with a transcript or similar text alternative.
Check for a control that indicates that activating it will supply static alternative content for the media. Activate the control.
Verify that the media control is replaced with alternate content, and that assistive technologies represent the change to the user interface.

期待される結果

#3 is true.

SL18: Providing Text Equivalent for Nontext Silverlight Controls With AutomationProperties.Name

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する
達成基準 2.4.4 (リンクの目的 (コンテキスト内) )
- クイックリファレンス 2.4.4 (リンクの目的 (コンテキスト内) )
- 達成基準 2.4.4 (リンクの目的 (コンテキスト内) )を理解する
注記: この達成方法は、達成基準 2.4.4 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 2.4.4 を理解するを参照すること。
達成基準 2.4.9 (リンクの目的 (リンクのみ) )
- クイックリファレンス 2.4.9 (リンクの目的 (リンクのみ) )
- 達成基準 2.4.9 (リンクの目的 (リンクのみ) )を理解する
達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- クイックリファレンス 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- 達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )を理解する

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

SL18 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to use the Silverlight AutomationProperties.Name property to provide a short text alternative for controls that do not otherwise contain text. The text is intended to provide human-readable identifiers and short-descriptions or user instructions for accessibility frameworks, which can then be reported to assistive technologies.

"Control" in this technique refers to any element that is based on the Silverlight Control class, and is keyboard-focusable either by user action or calling focus to the control programmatically. The non-text control in question might be something like a button that communicates information using only an icon or image. For example, a triangle image rotated 90 degrees clockwise is commonly used in many user interfaces to indicate a "Play" button control. This "Play" icon mimics interface metaphors from many non-software consumer products, and is often presented in a user interface without any nearby visible text information that explains the purpose of the control. Another example is a "thumbnail" metaphor where a small image serves as a control that can be activated, and where the action results in the display of a larger version of the same image, or enters an editing mode that loads the same image.

For cases of controls such as buttons that invoke actions, the text alternative also identifies link purpose.

In Silverlight, a text-only identifier for any control can be set specifically as AutomationProperties.Name on the parent control. Silverlight control compositing techniques enable either per-control images that are specified by the application author, or a general-purpose image/icon for a control that is part of the control's template and displays that way by default. The Silverlight API AutomationProperties.Name directly sets Name in the UI Automation tree. The properties in the UI Automation tree are reported to assistive technologies, when the assistive technology implements behavior that acts as a UI Automation client (or as an MSAA client, which relies on the UIA-MSAA bridge).

事例

事例 1: Applying a text alternative for an icon Button with XAML

Application authors can specify the AutomationProperties.Name attribute on the Button element, and leave accessibility information for the composited Image content unspecified. It is the button and its action that is relevant to users, not the non-interactive Image component. The value provided for AutomationProperties.Name is a meaningful text alternative for the action conveyed by the button's icon/image, but where the functionality is conceptually embodied in the button and not its images or other constituent parts in compositing or visual design.

 <Button
   Height="20" Width="50"
   AutomationProperties.Name="Pause Media">
   <Image Height="12" Width="12" Source="/icon_pause.png"/>
 </Button>

This example is shown in operation in the working example of Button Text Alternative.

参考リソース

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

SL30: Using Silverlight Control Compositing and AutomationProperties.Name

検証

Accessibility framework view

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
Use a verification tool that is capable of showing the full accessibility framework tree, and an object’s "Name" text alternative as part of the tree. Verify that all interactive elements such as buttons without visible text provide a human-readable text identifier "Name" in the automation tree.

期待される結果

#2 is true.

検証

Screen Reader

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
Engage the screen reader. Press TAB to traverse the tab sequence inside the Silverlight content area to focus to a composite control that has no visible text, but has an AutomationProperties.Name applied.
Check that the "Name" as applied to the control instance, along with the class name of the named control, is read by the screen reader.

期待される結果

#3 is true.

SL19: Providing User Instructions With AutomationProperties.HelpText in Silverlight

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

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

SL19 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to provide a long text alternative that serves the same purpose and presents the same information as the original non-text content when a short text alternative is not sufficient, and to show the practice of storing that information in a dedicated property of the Silverlight-supported UI Automation support system. The technique can also be used on text controls (such as TextBox), for cases where the control text itself does not provide enough context to suggest an appropriate user action.

The relevant UI Automation property is named HelpText, to connote its possible usage to provide imperative instructions for interactive elements. However, the same property can instead be used for long text alternatives for nontext objects. The Silverlight API AutomationProperties.HelpText directly sets HelpText in the UI Automation tree. The properties in the UI Automation tree are reported to assistive technologies, when the assistive technology implements behavior that acts as a UI Automation client.

AutomationProperties.HelpText can be set in code, but is most typically set as an attribute in XAML that defines a Silverlight UI.

The same information as is present in AutomationProperties.HelpText could also be useful to sighted users. In this case, the same text could be displayed in a Silverlight ToolTip control. The reason that application authors should use both AutomationProperties.HelpText AND Tooltip in conjunction is because the Tooltip information is not introduced into the runtime accessibility framework information set. This is because a tooltip is transient and not conventionally focusable. In Silverlight programming, a useful technique for sharing the same resource is to combine the Silverlight data binding feature with the .NET Framework embedded resource feature. For more information on combining Silverlight data binding and resources for common string sources, see How to Make XAML Content Localizable.

事例

事例 1: Applying a long text alternative for an Image with XAML

To introduce the necessary information to Silverlight XAML for an application UI definition, specify the AutomationProperties.HelpText attribute on the Image element. The value provided for the attribute is a meaningful long text alternative for the image content. The value of AutomationProperties.HelpText should augment rather than duplicate AutomationProperties.Name, which is also typically specified to provide accessibility support for an image.

 <Image
   Height="400" Width="600"
   Source="/office.png"
   AutomationProperties.Name="Diagram of standard office layout"
   AutomationProperties.HelpText=”The standard office layout
includes one corner desk unit in the corner farthest from the
door, and one file cabinet against the same wall as the door.”/>

事例 2: Using HelpText as form instructions

This example provides instructions for two form fields by using both Tooltip and AutomationProperties.HelpText. The strings used for these purposes are shared to both methodologies by defining the strings as resources and binding to them. In this example, the form submission does not perform client-side validation (although server-side validation following a data round trip might still exist).

The following is the XAML UI:

<UserControl xmlns:sdk="http://schemas.microsoft.com/winfx/2006/xaml/presentation/sdk" 
   x:Class="HelpTextAndToolTip.MainPage"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
       <Grid x:Name="LayoutRoot" Background="White" Margin="10">
           <Grid.RowDefinitions>
               <RowDefinition Height="Auto"/>
               <RowDefinition Height="Auto"/>
               <RowDefinition Height="Auto"/>
               <RowDefinition Height="Auto"/>
               <RowDefinition Height="Auto"/>
           </Grid.RowDefinitions>
           <Grid.ColumnDefinitions>
               <ColumnDefinition Width="Auto"/>
               <ColumnDefinition Width="200"/>
               <ColumnDefinition Width="Auto"/>
           </Grid.ColumnDefinitions>
           <TextBlock Text="Form With Tooltips" FontSize="16" FontWeight="Bold"
     Grid.Column="1" HorizontalAlignment="Center" />
           <sdk:Label x:Name="NameLabel" Target="{Binding ElementName=NameTextBox}"
     Grid.Row="2" Margin="3"/>
           <TextBox x:Name="NameTextBox" 
     AutomationProperties.Name="{Binding Content, ElementName=NameLabel}"
     Text="{Binding Name, Mode=TwoWay, UpdateSourceTrigger=Explicit}"
     Grid.Column="1" Grid.Row="2" Margin="3"
     AutomationProperties.HelpText="{Binding
       NameTextBoxToolTipString,Source={StaticResource TooltipStrings}}">
           <ToolTipService.ToolTip>
               <ToolTip Content="{Binding NameTextBoxToolTipString,Source={StaticResource TooltipStrings}}" />
           </ToolTipService.ToolTip>
           </TextBox>
           <sdk:Label x:Name="AgeLabel" Target="{Binding ElementName=AgeTextBox}"
     Grid.Row="3" Margin="3" HorizontalAlignment="Right"/>
           <TextBox x:Name="AgeTextBox" 
     AutomationProperties.Name="{Binding Content, ElementName=AgeLabel}" 
     Text="{Binding Age, Mode=TwoWay, UpdateSourceTrigger=Explicit}"  
     Grid.Column="1" Grid.Row="3" Margin="3"
    AutomationProperties.HelpText="{Binding AgeTextBoxToolTipString,Source={StaticResource TooltipStrings}}">
           <ToolTipService.ToolTip>
               <ToolTip Content="{Binding AgeTextBoxToolTipString,Source={StaticResource TooltipStrings}}" />
           </ToolTipService.ToolTip>
       </TextBox>
           <Button x:Name="SubmitButton" Content="Submit" Click="SubmitButton_Click"
             Grid.Column="1" Grid.Row="4" Width="50" Margin="3" />
       </Grid>
</UserControl>

The following is the resource definition in app.xaml:

       <ResourceDictionary>
           <resources:Resource1 x:Key="TooltipStrings"/>
       </ResourceDictionary>

The generated resource code that defines the "Resource1" class is not shown here because it is mostly infrastructure that is produced by a generation task in Visual Studio. For more information about embedded resources in Silverlight, see Resources Overview on MSDN. The resources here contain just two strings, each of which would typically be defined in a Visual Studio .resx file. Resources in a .resx file can be localized or changed separately from code by the appropriate localization toolsets for Microsoft localization/development.

NameTextBoxToolTipString: Must be 10 characters or less. Required.
AgeTextBoxToolTipString Must be a value between 0 and 120. Required.

These examples are shown in operation in the working example of Automation Properties Help Text and working example of HelpText and ToolTip.

参考リソース

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

SL8: Displaying HelpText in Silverlight User Interfaces

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. To see UI Automation, use Microsoft Windows as platform.
Use a verification tool that is capable of showing the full automation tree, and an object’s long text alternative as part of the tree. (For example, use UIAVerify or Silverlight Spy; see Resources links.)
Focus an element that is known to have a long text alternative. Check that the AutomationProperties.HelpText as applied to individual UI elements appears as the HelpText or acc_Help value in the automation tree.

期待される結果

#3 is true.

SL20: Relying on Silverlight AutomationPeer Behavior to Set AutomationProperties.Name

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

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

SL20 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to illustrate how in certain cases, the Silverlight automation peer system can provide an accessibility framework Name based on any simple text strings that are also presented in the visible user interface as control content.

The applicability of this technique to SC 1.3.1 is that once promoted, the Name becomes the primary information item that describes the user interface element to accessibiity frameworks and assistive technologies, and the information is thus immune to any further applications of the Silverlight style system that might change the appearance of the visual text equivalent (styled with color, uses italic font for rendering basis, etc.)

The applicability of this technique to SC 4.1.2 is that the default peer promotion behavior provides the Name component of Name, Role, Value. This is related to the description of the term label in SC4.1.2.

A default behavior for generating Name for accessibility frameworks is possible for certain peers of content controls. The content controls that might support a default automation peer behavior include:

TextBlock
ButtonBase derived classes that do not change the GetNameCore implementation. This includes the Button class. In order for the default promotion to work, the Content of the button must be set as a plain string or must contain only a TextBlock; any compositing such as wrapping in a Border or other container will disable the default promotion.
Any other ContentControl derived class where the Content property contains either TextBlock or a text-content-only ButtonBase implementation as sole content.

In these cases the string that sets either Content (for ContentControl and ButtonBase) or Text (for TextBlock) is promoted as the AutomationProperties.Name for the control in UI Automation, without any further attribution. The properties in the UI Automation tree are reported to accessibility frameworks (UI Automation, and MSAA through the bridge). The accessibility frameworks reports this information to assistive technology clients.

Relying on default automation peer behavior is the preferred Silverlight technique for supplying the accessibility framework "Name" information, so long as the default peer promotion actually does produce a usable name. Using default behavior is preferred because re-using the strings that are already used in the general visual presentation is less likely to result in accessibility-specific strings being forgotten by the application author, or get decoupled from visible UI in a revision process.

For cases where there is control compositing in a control rather than simple text, the automation peer typically cannot provide a default simple string, and it may be the application author's responsibility to set AutomationProperties.Name explicitly as an attribute in XAML, or as a property in runtime code. For details, see SL30: Using Silverlight Control Compositing and AutomationProperties.Name.

Test-based methodology

In order to use this technique effectively, application authors are expected to be following a test-based methodology towards verifying what information their application is reporting to any pertinent accessibility framework. Useful tools for this purpose include SilverlightSpy and UIAVerify. Application authors might examine their running Silverlight application on a test machine where the accessibility framework test viewers are also active. Initially, the application author might view the application at a point in the application development cycle that is prior to any effort devoted to specifically adding accessibility-related information to the application. Silverlight applications might be in this state because the initial user interface design was done in a visually oriented design tool such as Microsoft Expression Blend. Using the test-based methodology, application authors might note that certain accessibility framework properties are already populated, as a result of the mechanisms that are described in this technique. However, it is rare that ALL of the necessary accessibility information for an application can be obtained entirely from the built-in default behaviors of the automation peers. At this point, the application author may have to apply additional Silverlight techniques that provide accessibility framework information, for example SL30: Using Silverlight Control Compositing and AutomationProperties.Name.

事例

事例 1: Button is composed with direct text content only

The following example shows XAML UI only. Logic is not shown, but would typically be added by referencing a Click handler from the XAML.

 <Button Height="20" Width="200">Fire photon torpedoes!</Button>

The following illustration shows the UIAVerify tree view of this simple interface. Note that the internal string "Fire photon torpedoes!" is being peer-forwarded. This is verified by the Properties view on the right side: the Name property value is "Fire Photon Torpedoes", even though no programmatic Name property or AutomationProperties.Name has been applied to that button that would otherwise have supplied an acccessibility framework "Name".

UIAVerify tree view

This example is shown in operation in the working example of Simple Peer Forwarding.

参考リソース

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

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. To use UI AUtomation, use Windows as the platform.
Use a verification tool that is capable of showing the full automation tree, and an object’s name text alternative as part of the tree. (For example, use UIAVerify or Silverlight Spy; see Resources links.)
Check that any element where default automation peer promotion is expected is supplying a default Name in the automation tree.

期待される結果

#3 is true.

SL21: Replacing A Silverlight Timed Animation With a Nonanimated Element

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

達成基準 2.2.1 (タイミング調整可能)
- クイックリファレンス 2.2.1 (タイミング調整可能)
- 達成基準 2.2.1 (タイミング調整可能)を理解する

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

SL21 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to replace a timed Silverlight animation with a non-timed user interface element that presents equivalent information. This is useful in cases where the Silverlight animation is a timed animation that may contain information that the user wants to see without a time limit, such as crawling text in a text area. The animated version of information in the user interface element can instead be swapped out for an equivalent static element.

事例

事例 1: Stopping an animation that is scrolling text, replacing the animation with a full text alternative

This example has a UI definition in XAML and interaction logic in C#. The following is the basic UI in XAML.

<UserControl x:Class="StopAnimation.MainPage"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:sys="clr-namespace:System;assembly=mscorlib">
   <UserControl.Resources>
       <ImageBrush x:Key="Stars" ImageSource="/stars.jpg" Stretch="Fill"/>
       <Storyboard x:Key="crawl">
           <DoubleAnimation From="700" To="-100" Duration="0:0:20"
             Storyboard.TargetName="crawltext" Storyboard.TargetProperty="(Canvas.Top)"/> 
       </Storyboard>
       <sys:String x:Key="crawlText">
           Episode IV, A NEW HOPE It is a period of civil war. Rebel spaceships, striking from a hidden base, 
           have won their first victory against the evil Galactic Empire. During the battle, Rebel spies managed 
           to steal secret plans to the Empire’s ultimate weapon, the DEATH STAR, an armored space station with 
           enough power to destroy an entire planet. Pursued by the Empire’s sinister agents, Princess Leia 
           races home aboard her starship, custodian of the stolen plans that can save her people and restore 
           freedom to the galaxy….
       </sys:String>
   </UserControl.Resources>
   <StackPanel x:Name="LayoutRoot"
   Background="{StaticResource Stars}"
   Height="600" Width="800">
       <Button Width="200"
   Click="Button_Click">Stop crawling text, display fixed text</Button>
       <Canvas Name="CrawlPanel" Width="605" Height="595" >
           <Canvas.Projection>
               <PlaneProjection RotationX="-75"/>
           </Canvas.Projection>
           <Canvas.Clip>
               <RectangleGeometry Rect="0 0 600 600"/>
           </Canvas.Clip>
           <TextBlock Text="{StaticResource crawlText}"
   TextWrapping="Wrap" FontSize="20"
   Width="300" Canvas.Left="150" Name="crawltext"
   Foreground="Goldenrod"/>
       </Canvas>
   </StackPanel>
</UserControl>

The following is the C# logic. In this example, the animation starts automatically. When the user activates the control (the Button), the event handler stops the animation, removes the animated element from the visual tree, and replaces it with a fixed text element that presents all text at once. Because it is a TextBox, assistive technologies could identify the newly introduced text element and present it, for example read the text in a screen reader.

       public MainPage()
       {
           InitializeComponent();
           (this.Resources["crawl"] as Storyboard).Begin();
       }
       private void Button_Click(object sender, RoutedEventArgs e)
       {
           (this.Resources["crawl"] as Storyboard).Stop();
           LayoutRoot.Children.Remove(CrawlPanel);
           TextBox tb = new TextBox();
           tb.IsReadOnly = true;
           tb.FontSize = 30;
           tb.TextWrapping = TextWrapping.Wrap;
           tb.Text = (string)this.Resources["crawlText"];
           LayoutRoot.Children.Add(tb);
       }

This example is shown in operation in the working example of Stop Text Animation.

参考リソース

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

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. For a Silverlight application that has a time limit on interaction due to an animated user interface element:
Check for a mechanism to stop the time limit on interaction.
When the mechanism is activated, check that the element that is animated and resulting in a time limit is removed, and the time-limited element is replaced with static content that is equivalent and does not have a time limit.

期待される結果

#3 is true.

SL22: Supporting Browser Zoom in Silverlight

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

Silverlight content in a user agent host that supports browser zoom

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.4 (テキストのサイズ変更)
- クイックリファレンス 1.4.4 (テキストのサイズ変更)
- 達成基準 1.4.4 (テキストのサイズ変更)を理解する

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

SL22 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to support or anticipate existing browser zoom features effectively when users interact with the Silverlight application. This technique explains how the Silverlight content area reacts to the browser zoom feature implemented by some user agent hosts. Silverlight content and layout properties are based on physical screen pixel measurements. When the browser zoom is engaged, Silverlight content scales correctly for the zoom factor, and uses the same zoom factor as any surrounding HTML content.

Browser zoom is relevant for accessibility and Silverlight because it is likely to be the zoom /scaling feature enabled by the browser host that Web technology users are the most familiar with as a technique for increasing the text size in Web content.

Legacy behavior in Silverlight version 2

Built-in support for browser zoom was introduced as a feature in Silverlight version 3. Older documents on the Web might describe techniques that were relevant for Silverlight version 2, where dealing with browser zoom required JavaScript handling of the Resized event, and developers manually applied a ScaleTransform to Silverlight content to scale it up. Silverlight has a "quirks mode" that detects existing handlers that might still use the older techniques. Built-in zoom not active in these cases, so that applications can avoid doubling or otherwise mishandling the user agent's zooming behavior.

Deliberately disabling browser zoom in Silverlight applications

Silverlight also provides the ability to disable the built-in browser zoom handling and rendering behavior. This is sometimes done in order to suppress some of the aliasing and distortion artifacts that host-level scaling can introduce, particularly for video content or certain uses of text. In these cases, application authors might consider other Silverlight techniques for scaling the user interface, perhaps specifically only for the text elements on a page. When an application disables the built-in zoom behavior and rendering for Silverlight content, the browser still retains its zoom settings, and that setting applies to other content outside of Silverlight such as the hosting HTML.

事例

事例 1: Verifying browser zoom, and checking the zoom factor

This example has a UI defined in XAML and logic defined in C#. The UI shows the zoom factor, and also demonstrates what happens when built-in browser zoom handling is deliberately disabled. Note that the zooming factor as reported by the API is still retained even when Silverlight built-in zoom scaling is disabled deliberately. The following is the XAML UI:

<UserControl x:Class="BrowserZoom.MainPage"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
   <StackPanel x:Name="LayoutRoot" Background="White">
       <TextBlock>Some text you can zoom.</TextBlock>
       <Button Click="Button_Click">Toggle built-in zoom handling</Button>
       <StackPanel Orientation="Horizontal">
           <Button Click="Button_Click_1">Query current zoom factor</Button>
           <TextBox IsReadOnly="true" Name="zoomf"
   Text="{Binding Path=reportZoom}"/>
       </StackPanel>
   </StackPanel>
</UserControl>

The following is the C# logic:

   public partial class MainPage : UserControl
   {
       public MainPage()
       {
           InitializeComponent();
       }
       private void Button_Click(object sender, RoutedEventArgs e)
       {
           if (!Application.Current.Host.Settings.EnableAutoZoom == false) {
           Application.Current.Host.Settings.EnableAutoZoom = false;
           }
           else
           {
               Application.Current.Host.Settings.EnableAutoZoom = true;
           }
       }
       private void Button_Click_1(object sender, RoutedEventArgs e)
       {
           zoomf.Text = Application.Current.Host.Content.ZoomFactor.ToString();
       }
   }

This example is shown in operation in the working example of Browser Zoom.

参考リソース

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

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. The browser being used for the test must support a browser zoom feature, and the feature must be turned on as a user preference.
Verify that the Silverlight application enables auto zoom (no Silverlight application-specific code or markup has set EnableAutoZoom API to false).
Test the zooming feature of the user agent. Verify that browser zoom factors apply to the Silverlight content.

期待される結果

#2 and #3 are true.

SL23: Using A Style Switcher to Increase Font Size of Silverlight Text Elements

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

達成基準 1.4.4 (テキストのサイズ変更)
- クイックリファレンス 1.4.4 (テキストのサイズ変更)
- 達成基準 1.4.4 (テキストのサイズ変更)を理解する

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

SL23 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to define style switching logic for Silverlight. In particular, the intent is to use the style switcher to change the font size of text elements. This technique could be used only for specific elements, or could also be applied to the entire Silverlight content area and all text elements therein (including elements such as TextBlock that are technically not controls). Examples are provided for these two cases.

The property to style or otherwise change is the FontSize property. Primarily, this is done using the API Control.FontSize, but developers can also use similar properties on other objects that do not derive from Control (examples: TextBlock; DataGridTextColumn).

Silverlight uses a style system whereby many properties that affect UI appearance can be referred to and changed through a style resource. The style resource overrides the default code implementation and the default XAML template as provided by the Silverlight core implementation(or a third party control author). A style enables an application author to make a one-to-many change to property values in an efficient and reversible way, and also to group multiple related property changes as one unit of logic. Styles can be applied explicitly by referencing them by name, or implicitly by associating a style with a class (which then targets all instances of that class). This is analogous to how CSS can either define styles globally for tags or uniquely for classids and names.

Silverlight styles are always written in XAML. Silverlight event handlers are most often written in code (there are related techniques that can react to states with event associations, defined in pure XAML, but the specific style switching technique is most straightforward in code).

Using this technique versus relying on browser zoom

Silverlight supports browser zoom when viewed in browser hosts that support a browser zoom feature. Specifically, Silverlight scales content within its content area when the user engages browser zoom, based on the browser zoom factor. However, not all browser hosts that Silverlight supports have a browser zoom feature, and/or users might choose not to use browser zoom. This technique presents an alternative technique for font scaling in cases when relying on browser zoom is not viable as a technique. Applications might use HTML DOM based logic to determine the user agent string of the browser host, and use that as a determinant of whether the user has browser zoom available as an option. If no browser zoom feature exists for that user and their user agent, that user could be served a version of the Silverlight application that presents a UI and logic for sizing the fonts using the Silverlight API, as described in this technique.

For more information about Silverlight and browser zoom, see the technique SL22: Supporting Browser Zoom in Silverlight.

Sizing by percent

Generally, sizing Silverlight FontSize values by percentages is not recommended. Sizing by percentage produces non-integer font size values, which in turn produce aliasing artifacts. The Silverlight rendering routines for text work best when dealing with integer numbers. The entire Silverlight rendering system is based on pixel measurements. In particular, the behavior for text rendering produces optimized font shaping and subpixel rendering for text areas, and this behavior is based on the assumption that font unit measurements will be provided by applications using whole pixel values.

Units for font sizing in Silverlight

Font sizing in Silverlight is always specified by a unit measure of pixels. Other unit measures such as ems or points that come from a migrated UI definition in XAML would need to be unit-converted to all use a purely numeric value, such that attribute values in XAML do not not include unit identifier suffixes such as "px", "pt", "em", or "cm". This note is most relevant if the application author is porting or migrating a Windows Presentation Framework (WPF) application to Silverlight, or is using a XAML-emitting design tool that is producing general XAML UI definitions and not targeting a specific framework.

事例

事例 1: Style applied to all text elements within a RichTextBox container

Variations of this example could be employed to offer more choices. For example, multiple style switchers could be provided that gave three or more fontsize choices.

<UserControl x:Class="StyleSwitcherFontSize.MainPage"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
   <UserControl.Resources>
       <Style x:Key="BiggerRTBFonts" TargetType="RichTextBox">
           <Setter Property="FontSize" Value="24"/>
       </Style>
   </UserControl.Resources>

   <StackPanel x:Name="LayoutRoot" Background="White">
       <Button Click="Button_Click">Super size fonts!</Button>
       <Button Name="Undo" Click="Undo_Click">Make those big fonts stop!</Button>
       <RichTextBox IsReadOnly="True" Name="rtb1">
           <RichTextBox.Blocks>
               <Paragraph>Various test text</Paragraph>
               <Paragraph>
                   <Bold>Some bold test text</Bold></Paragraph>
               <Paragraph>
                   <Italic>Some italic</Italic>
               </Paragraph>
               <Paragraph FontFamily="Times New Roman">A different font, why not?</Paragraph>
           </RichTextBox.Blocks>
       </RichTextBox>
   </StackPanel>
</UserControl>

The second listing is the C# code for the event handler . Note that all it does is change a style property, using a value that keys into the .Resources collection from XAML where the Style is defined. Another event handler nulls out the style and returns values to defaults.

private void Button_Click(object sender, RoutedEventArgs e)
{
  rtb1.Style = this.Resources["BiggerRTBFonts"] as Style;
}
private void Undo_Click(object sender, RoutedEventArgs e)
{
   rtb1.Style = null;
}

The following images show the original, and the applied style.

Screen shot with standard fonts and a button to enlarge

Screen shot with enlarged fonts after activating button to enlarge

This example is shown in operation in the working example of Style Switcher Font Size.

事例 2: Font size increase applied to all text content by applying at UserControl level, and by percent increase logic

This example uses the inheritance characteristics of the FontSize property that is available to all Silverlight controls. Rather than using a style, this example uses a HoldEnd animation, to take advantage of the "By" behavior of the animation system that can increment an existing value by 2 (pixels) rather than replacing the value with a fixed pixel value.

The following is the XAML UI:

<UserControl x:Class="StyleSwitcherFontSize.MainPage"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   Name="rootcontrol">
   <UserControl.Resources>
       <Storyboard x:Key="BySize">
           <DoubleAnimation Storyboard.TargetName="rootcontrol" Storyboard.TargetProperty="FontSize" By="2" FillBehavior="HoldEnd" Duration="0"/>
       </Storyboard>
   </UserControl.Resources>
   <StackPanel x:Name="LayoutRoot" Background="White">
       <Button Click="Button_Click">Super size fonts!</Button>
       <Button Name="Undo" Click="Undo_Click">Make those big fonts stop!</Button>
       <TextBox Text="Various test text"/>
       <TextBox FontWeight="Bold" Text="Some bold test text"/>
       <TextBox FontStyle="Italic" Text="Some italic"/>
       <TextBox FontFamily="Times New Roman" Text="A different font, why not?"/>
   </StackPanel>
</UserControl>

The following are the C# event handlers.

private void Button_Click(object sender, RoutedEventArgs e)
{
   (this.Resources["BySize"] as Storyboard).Begin();
}
private void Undo_Click(object sender, RoutedEventArgs e)
{
   (this.Resources["BySize"] as Storyboard).Stop();
}

This example is shown in operation in the working example of By Animation Font Size.

参考リソース

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

C29: 適合している代替版を提供するために、スタイルスイッチャーを使用する

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
Verify that the application provides a control that can increase font size.
Activate the control, and check that the font sizes increase.

期待される結果

#2 and #3 are true.

SL24: Using AutoPlay to Keep Silverlight Media from Playing Automatically

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

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

SL24 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to use the AutoPlay property of MediaElement object, which prevents the MediaElement from playing its media source automatically.

By default the value of AutoPlay is true, which causes any media that is the Source of the MediaElement to play as soon as either the entire source file is loaded (for nonstreaming media) or an initial buffer is loaded (for streaming media). To prevent the possible accessibility issues, developers can instead specifically set AutoPlay to false, so that the user always controls whether the media plays. This technique would thus be used in combination with providing user interface controls that go along with the MediaElement, and that enable the user to control the media. In particular, the user interface controls enable the media to play, pause or stop, with event wiring for those controls associated with the Play, Pause or Stop methods of the MediaElement object.

事例

事例 1: Setting AutoPlay to false, and providing the typical MediaElement controls in the UI

This example has a UI definition in XAML and interaction logic in C#.

The following is the basic UI in XAML. Note the AutoPlay="false" setting.

<UserControl x:Class="MediaElementControlsAutoPlay.MainPage"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  >
   <Grid x:Name="LayoutRoot">
       <Grid.ColumnDefinitions>
           <ColumnDefinition Width="*" />
           <ColumnDefinition Width="*" />
           <ColumnDefinition Width="*"/>
       </Grid.ColumnDefinitions>
       <Grid.RowDefinitions>
           <RowDefinition Height="*" />
           <RowDefinition Height="Auto" />
       </Grid.RowDefinitions>
       <MediaElement x:Name="media" Source="/xbox.wmv"
          Width="300" Height="300" 
          Grid.Column="0" Grid.Row="0" Grid.ColumnSpan="3"
          AutoPlay="False"
          AutomationProperties.Name="Video of new Fable game for XBox"           
       />
       <Button Click="StopMedia" 
    Grid.Column="0" Grid.Row="1" Content="Stop" />
       <Button Click="PauseMedia" 
    Grid.Column="1" Grid.Row="1" Content="Pause" />
       <Button Click="PlayMedia" 
    Grid.Column="2" Grid.Row="1" Content="Play" />
   </Grid>
</UserControl>

The following is the C# logic.

 private void StopMedia(object sender, RoutedEventArgs e)
 {
     media.Stop();
 }
 private void PauseMedia(object sender, RoutedEventArgs e)
 {
     media.Pause();
 }
 private void PlayMedia(object sender, RoutedEventArgs e)
 {
     media.Play();
 }

This example is shown in operation in the working example of Media Element Controls with AutoPlay False.

参考リソース

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

Audio and Video Overview
MediaElement Class
Silverlight Media Framework - a framework and a media player control implementation that incorporates many of the Silverlight techniques related to MediaElement

SL17: Providing Static Alternative Content for Silverlight Media Playing in a MediaElement

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. The application is expected to use a MediaElement object to play prerecorded media.
Check that the media does not play automatically as soon as the application loads and displays. Rather, the user is presented with a user interface that can start the media per the user's action.

期待される結果

#2 is true.

SL25: Using Controls and Programmatic Focus to Bypass Blocks of Content in Silverlight

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.1 (ブロックスキップ)
- クイックリファレンス 2.4.1 (ブロックスキップ)
- 達成基準 2.4.1 (ブロックスキップ)を理解する

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

SL25 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to use the combination of Silverlight control activation and programmatic focus to enable the user to skip regions of content in a Silverlight application user interface.

The control that the user activates should clearly indicate that its purpose is to skip content, so that the resulting programmatic focus shift is not interpreted as an undesired change of context.

The object to call focus to (the receiver of focus after the user-initiated action is triggered) has to be a Control in the Silverlight programming model. This is because the Focus method must be called on the target, and therefore the target must inherit the Control class. So, an application author might call focus to a read-only TextBox, or perhaps a RichTextBox, depending on the purpose of the Silverlight application and its user interface design. You can also focus a UserControl, for cases where the area to call focus to represents a custom control implementation.

Setting TabIndex (not recommended)

Silverlight provides a TabIndex attribute that can be used to override the default-generated tab sequence. Do not attempt to adjust tab index as a technique for getting past content blocks. Doing so will create a focus order that does not match the apparent visual order, as described in SC 2.4.3.

事例

事例 1: User-enabled control that programmatically sets focus

The following is the XAML for the user interface.

   <StackPanel Name="LayoutRoot">
       <Button Name="bypassbtn1" Click="bypassbtn1_Click">Skip menus, go to main page content</Button>
       <!intervening content-->
       <StackPanel>
           <RichTextBox Name="rtb_MainContent" IsReadOnly="True">
           <Paragraph>Here is the main content ....</Paragraph>
           </RichTextBox>
       </StackPanel>
   </StackPanel>

The following is the event handler that forces focus.

       private void bypassbtn1_Click(object sender, RoutedEventArgs e)
       {
           rtb_MainContent.Focus();
       }

This example is shown in operation in the working example of Programmatic Focus.

参考リソース

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

G123: 繰り返しているコンテンツのブロックの先頭に、そのブロックの末尾へのリンクを追加する

検証

手順

Open the test HTML page for a Silverlight application.
Check for a control that indicates that activating that control can skip to some particular region of the content.
Activate that control. Verify that activating the control causes focus to go to that region, and that a repeated block or blocks of content are skipped.

期待される結果

#2 and #3 are true.

SL26: Using LabeledBy to Associate Labels and Targets in Silverlight

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

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

SL26 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to use the AutomationProperties.LabeledBy property to associate a non-interactive text label with an interactive field such as a Silverlight TextBox or RichTextBox. By using this technique, application authors can use the label text as the default source for AutomationProperties.Name on the target, and do not need to specify an explicit AutomationProperties.Name.

This technique relies on several Silverlight features: the Name property for identifying specific UI elements, the AutomationProperties API, and the ElementName variation of Silverlight data binding. AutomationProperties.Name can be set on and can target any Silverlight UIElement. The two most common uses of this labeling technique are for labeling a form field, and for associating an image caption with an image.

事例

事例 1: Two TextBox form fields, each with a LabeledBy reference to a text label

The following is XAML for the UI (and can be inserted into a UserControl XAML root or elsewhere). No code-behind is necessary for this example; the element relationships are established by the {Binding} values in the XAML and interpreted appropriately by the Silverlight run time.

   <StackPanel x:Name="LayoutRoot" Background="White">
       <StackPanel Orientation="Horizontal">
           <TextBlock Name="lbl_FirstName">First name</TextBlock>
           <TextBox AutomationProperties.LabeledBy="{Binding ElementName=lbl_FirstName}" Name="tbFirstName" Width="100"/>
       </StackPanel>
       <StackPanel Orientation="Horizontal">
           <TextBlock Name="lbl_LastName">Last name</TextBlock>
           <TextBox AutomationProperties.LabeledBy="{Binding ElementName=lbl_LastName}" Name="tbLastName" Width="100"/>
       </StackPanel>
   </StackPanel>

This example is shown in operation in the working example of Labels.

事例 2: Labeling / captioning an image

       <Image HorizontalAlignment="Left" Width="480" Name="img_MyPix"
                Source="snoqualmie-NF.jpg"
                AutomationProperties.LabeledBy="{Binding ElementName=caption_MyPix}"/>
       <TextBlock Name="caption_MyPix">Mount Snoqualmie North Bowl Skiing</TextBlock>

注記: If the caption is not a usable text alternative, use the technique SL5: Defining a Focusable Image Class for Silverlight, or change the caption text.

参考リソース

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

AutomationProperties.LabeledBy
Tools: SilverlightSpy or UIAVerify

SL35: Using the Validation and ValidationSummary APIs to Implement Client Side Forms Validation in Silverlight

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. To see UI Automation, use Microsoft Windows as platform.
Use a verification tool that is capable of showing the full automation tree. (For example, use UIAVerify or Silverlight Spy; see Resources links.)
Verify that any element that has a LabeledBy value has an associated visible label.
Verify that any element that has a LabeledBy value uses the Name value from that label.

期待される結果

#3 and #4 are true.

SL27: Using Language/Culture Properties as Exposed by Silverlight Applications and Assistive Technologies

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.2 (一部分の言語)
- クイックリファレンス 3.1.2 (一部分の言語)
- 達成基準 3.1.2 (一部分の言語)を理解する

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

SL27 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to use the combination of HTML Lang attribute, CultureInfo and Language to correctly specify the language of the entirety of Silverlight content, or of parts within the Silverlight content.

In general, Silverlight does not attempt to repurpose HTML Lang, because Silverlight is not HTML. Instead, internally within the Silverlight content area, Silverlight uses language definition concepts that relate to XML (Language is a remapping of xml:lang) or .NET Framework programming (CultureInfo). For these reasons, HTML Lang techniques as described in [H58] are not useful for Silverlight programming of Silverlight-specific "parts".

What becomes important in Silverlight application programming then is to make sure that the HTML language concept of Lang and the Silverlight language concept of CultureInfo or Lang are not at odds with one another, or reporting misinformation. In particular, application authors should avoid situations where an assistive technology has HTML Lang available for programmatic determination of either page or part, but the effective runtime language in the Silverlight part is different. The result here might be that a screen reader that changes functionality such as phonetic pronunciations would not correctly read the text content from the Silverlight content. Avoiding this situation is largely a matter of due diligence on the part of a Silverlight application author, OR on the part of the Web page author who authors surrounding HTML, in cases where a Web page is embedding Silverlight content or packages that the Web page's author did not actively develop and is only consuming/embedding.

The following is a general recommendation that summarizes the detailed discussion in subsequent subheadings:

If the Silverlight application does not have a strong emphasis on presenting textual information with a particular language association, HTML Lang should be left blank. This causes assistive technologies to defer to either user agent or platform language settings. Silverlight is able to determine these same language values at run time, and language behavior of assistive technologies and of Silverlight is kept synchronized through the use of the same external information set.
If the Silverlight application DOES have a strong emphasis on presenting textual information with A SINGLE particular language association, HTML Lang should be assigned to report that specific language either for whole page or at least for the Silverlight object tag. This enables assistive technologies to pick up the value, per H57: Using language attributes on the html element HTML. Aside from due diligence during development and deployment, Silverlight application code might choose to enforce that its runtime CultureInfo is really the same. This could be addressed with a specific HTML DOM helper function.
If the Silverlight application has MULTIPLE language associations, the best option is to separate the Silverlight application into object parts at the HTML level, to assure that HTML Lang and intended runtime language do not clash. This is particularly important if the application is actively resetting CurrentCulture away from the user settings of platform or user agent. For more information, see SL4: Declaring Discrete Silverlight Objects to Specify Language Parts in the HTML DOM.

HTML Lang

When Silverlight is embedded in an HTML document with the <object> element, the value of the HTML Lang attribute of the surrounding HTML becomes a factor. Browsers process the outer HTML, and the browser's processing has possible influence over values reported to any DOM script that acts, or to any accessibility framework that is reporting the browser content. The preferred way for a Silverlight application to address SC 3.1.1 is to correctly specify the HTML Lang value in the hosting HTML page. This technique should be used in conjunction with H57: Using language attributes on the html element HTML. By using the same language values with both techniques as a better practice, H57 will satisfy 3.1.1 while setting the language value of the Silverlight content to match will assist authors in meeting SC 3.1.2.

The Silverlight runtime itself does not attempt to inherit language settings that come from markup that is outside the Silverlight-specific content. In particular, the HTML Lang attribute applied to the html tag, Lang on host object tag, specific parameters of the Silverlight object tag, all have no affect on the value of any Silverlight Language attribute. Instead, the Silverlight Language defaults to the CultureInfo of the Silverlight runtime as instantiated by HTML object tag invocation. It is expected that if a Silverlight application contains extensive text where language of text is a factor for assistive technology purposes, developers will manually set the HTML Lang tag to match the Language value on the Silverlight root element in XAML. Development tools might or might not enforce or inform the relationship between HTML Lang and Silverlight Language; that consideration is outside the scope of Silverlight as a technology. If language is not a major factor in the application, application authors should consider leaving HTML Lang blank on the hosting HTML page.

You can programatically determine the value of HTML Lang of surrounding HTML from within the Silverlight API, by using the DOM-bridging method HtmlElement.GetAttribute. Otherwise, this can be determined by techniques other than Silverlight's (such as scripting to the HTML DOM of the hosting browser).

Silverlight Language property

Language is an attribute that is available on all Silverlight objects that directly represent a UI element. Language can be queried (or set) by Silverlight managed code run time, such that the Language value can be programatically determined within the Silverlight programming model.

The format of the value that is used to set Language is based on ISO-639-1, and is thus compatible with http://www.rfc-editor.org/rfc/bcp/bcp47.txt.

Language has a behavior that parallels the behavior of xml:lang in an XML document: if Language is set on a parent element, all child elements inherit that Language value. An actual xml:lang attribute in XAML is also valid for this purpose.

Language can be set at the root of a XAML document, so that the entire UI shares the same language setting. If Language is not explicitly set at the root by application markup, Language is inferred per running instance, based on processing the acting CultureInfo at run time.

However, another usage is for application authors to set Language on a specific child element, to override the root-level or client-environment-inferred Language value. This enables consciously embedding a content part that is deliberately in a different language than the remainder of the Silverlight content.

Exactly what happens when a Language is set on a part is not always specified, and is largely a matter of implementation detail of the individual Silverlight classes that might be a "part". However, as an informative generalization, the value of Language might affect considerations such as: how white space is processed (in particular CR or LF); character sets for fonts; string formatting when using APIs specifically on that part.

CultureInfo

CultureInfo is a concept that is relevant to .NET Framework programming. This concept applies to Silverlight because Silverlight uses a specific implementation of a CLR runtime that uses .NET Framework principles. CultureInfo potentially specifies both a language and a culture. This distinction becomes relevant for advanced string formatting concepts that are provided in the .NET Framework, such as decimal separators, dates, and currency. For example, an application author might simply specify "en" if the author did not care about string formatting, but might specify "en-GB" if the application was using string formatting for currency values with the intention of displaying Pounds Sterling as currency unit in string formatting.

Silverlight applications often run using an inferred CultureInfo based on the operating system where the user agent browser host exists (in other words, the culture of the client computer where the Silverlight application is run). This CultureInfo can be queried by applications at run time; see CultureInfo.CurrentCulture. Application authors can deliberately constrain the set of CultureInfo cases that a Silverlight application can be run under, in order to verify that necessary string resources for that culture are available in that application. This is done by setting <SupportedCultures> in the Silverlight project settings. If a user accesses the application on a client that is outside the SupportedCultures, the application author has the following choices:

Use a fallback resource set representing a neutral culture; this is enabled automatically by the Silverlight resources lookup behavior, so long as the project includes resources identified as being culture-neutral. This is the preferred approach.
Use client logic to detect the culture, and initiate a client-side redirect to request either a different XAP or a different hosting HTML page.
Trap requests at the server level by checking lang request in the header. This varies between server implementations, is not a Silverlight-specific technique, and is not discussed here.

For more information, see How to: Create a Build that Targets a Specific Culture.

CultureInfo generally applies to the Silverlight application as a whole. There are advanced techniques whereby worker threads can be run as separate cultures, but that is not discussed here and is not relevant because only the main UI thread has relevance to Web content accessibility. So, if an application author wants to declare specific language settings for a part (component, region or control) of the Silverlight application, a different Silverlight-specific property Language is used.

事例

These examples show Silverlight behaviors that are based on interpreting the Language property value, as a way of illustrating the programmatic determination of language values specifically in the Silverlight application framework. To determine HTML Lang, application authors should use the HTML DOM as enabled by browser host scripting, rather than Silverlight APIs. HTML DOM techniques are not shown here because they are specific to browsers or scripting frameworks, not to Silverlight.

事例 1: Language set at root-level of Silverlight content, inherits

This example features a XAML UI and logic that reports information to demonstrate that the information is programmatically determinable. This example shows determination of the Language property.

<UserControl x:Class="LangProperties.MainPage" 
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   Language="en-gb">
 <StackPanel x:Name="LayoutRoot" Background="White">
       <Border BorderBrush="Red" BorderThickness="2">
           <TextBlock Language="zh-cn" Text="（（）共" Name="t2" VerticalAlignment="Top" TextWrapping="Wrap" Height="100"/>
       </Border>
       <Border BorderBrush="Red" BorderThickness="2">
           <TextBlock Text="（（）共" Name="t3" VerticalAlignment="Top" TextWrapping="Wrap" Height="100"/>
       </Border>
       <Button Click="button1_Click">IETF Language of this app</Button>
 </StackPanel>
</UserControl

private void button1_Click(object sender, RoutedEventArgs e)
{
   Button b = sender as Button;
   MessageBox.Show(b.Language.IetfLanguageTag);
   // this will be 'en-gb' because inherits from the root
}

This example is shown in operation in the working example of Language Properties.

事例 2: Determine CurrentCulture; runtime verification that CurrentCulture and the surrounding HTML's current Lang value do not report different language settings

The following is an event handler that can be hooked to an object lifetime event such as UserControl.Loaded on the Silverlight XAML root. This example demonstrates property access to several of the relevant language properties that are present in Silverlight and shows a specific way to compare CultureInfo and Lang by a "not equals" check after constructing a CultureInfo based on the Lang string. To apply this test, the hosting HTML page may need to be altered to declare a specific HTML Lang; default Silverlight aspx or html test pages do not declare HTML Lang.

       private void RunLanguageDetectLogic(object sender, RoutedEventArgs e)
       {
           CultureInfo thisAppCC = CultureInfo.CurrentCulture;
           CultureInfo thisAppCUIC = CultureInfo.CurrentUICulture;
           HtmlDocument thisPage = HtmlPage.Document;
           String thisAppHTMLLang = (string) thisPage.DocumentElement.GetProperty("lang");
           CultureInfo CCFromLang = new CultureInfo(thisAppHTMLLang);
           if (CCFromLang != thisAppCC && CCFromLang.ToString() !=  "")
           {
               TextBlock tb = new TextBlock();
               tb.Text += "Warning: the current culture for the run time (";
               tb.Text += thisAppCC.ToString();
               tb.Text += ") does not match the culture indicated in hosting HTML's Lang (";
               tb.Text += CCFromLang.ToString();
               tb.Text += ").";
               tb.Inlines.Add(new LineBreak());
               tb.Inlines.Add("Typical action here would be to redirect the request to an HTML page
                 where the Lang is correct for user's current culture as determined from the OS.");
               LayoutRoot.Children.Add(tb); 
               //LayoutRoot refers to the default MainPage.xaml element from a VS-template Silverlight Application
           }
       }

参考リソース

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

Localizing Silverlight-based Applications

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
Verify that language settings are respected by individual Silverlight control characteristics. (Exactly what behavior manifests the language difference varies per Silverlight class implementation. For some testing ideas, see Creating Globally Aware Applications).
Verify that any interaction between HTML Lang in the HTML and the Language or CultureInfo from the Silverlight application do not result in a clash of language information, either in terms of basic application behavior or in how an assistive technology decides to process language information.

期待される結果

#2 and #3 are true.

SL28: Using Separate Text-Format Text Captions for MediaElement Content

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

達成基準 1.2.2 (キャプション (収録済) )
- クイックリファレンス 1.2.2 (キャプション (収録済) )
- 達成基準 1.2.2 (キャプション (収録済) )を理解する

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

SL28 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to use text captioning that comes from a separate text file, synchronize the captions with the media in a Silverlight MediaElement, and display the captions in Silverlight.

There are two variations of the general theme of implementing Silverlight media player controls to work with external timed text: using built-in capabilities of the Microsoft Expression Encoder tool, and using parsing code that consumes caption as a raw file format and converts that format into the Silverlight API's TimelineMarkers representation. This technique primarily addresses how to use the Expression Encoder technique, along with media player templates that are also provided by Expression Encoder or related Silverlight SDKs such as the Smooth Streaming SDK.

At a pure architecture level, Silverlight uses the TimelineMarkers API to display caption text at synchronized times. The Expression Encoder and Expression Blend tools provide a front end to drive the TimelineMarkers API for the supported formats. The intention of the architecture is so that Silverlight as a run-time has a base architecture that could potentially use any existing or future timed text format, but the tools for Silverlight (rather than built-in features of the runtime) provide the optimized workflow for producing captioned media projects.

A procedure for using the Expression Encoder and Expression Blend tools to produce a Silverlight media player application that can consume timed text in TTML format is provided as Example 1 in this technique. (Note: prior to the approval of TTML by W3C, DFXP was a format that used much of the eventual TTML vocabulary. In tools that predate TTML, this format is often identified as DFXP.)

A purely code-based parsing technique, with the goal of avoiding Expression Encoder dependencies, is necessarily more complex. This is because there are multiple issues to solve:

Obtaining and validating the timed text file
Parsing the format into general information items like timings, text, format etc. that are either consumable directly in a Silverlight API, or useful as intermediates
Using the timecode information to create TimelineMarker representations for each timed text entity
Associating the TimelineMarkers with media loaded by the player
Finding a place to store the additional formatting that is conveyed, including the text and any formatting
Handling events from TimelineMarkers in the media player, in such a way that text and formatting behavior can be retrieved and presented in the Text part of the player UI

Text Captioning Formats

There are several existing text-based formats that are used for text captioning of prerecorded media. The following are supported as formats if using the Expression Encoder tool as shown in Example 1 (where the Expression Encoder generated Silverlight application uses the existing Silverlight MediaPlayerTemplate and the TimedTextLibrary component.) For more information on which timed text formats can be referenced in an Expression Encoder project, see About Captioning (Expression documentation on MSDN).

SAMI (Synchronized Accessible Media Interchange). For more information on this format, see Understanding SAMI 1.0 on MSDN.
SMIL (Synchronized Multimedia Integration Language). For more information on this format, see Synchronized Multimedia Integration Language (SMIL 3.0) on W3C site.
TT (Timed Text) in particular TTML (Timed Text Markup Language). For more information, see Timed Text Markup Language (TTML) 1.0 on W3C site.
TTML (previously known as DFXP). This is the Timed Text format used by Adobe Flash for its FLVPlaybackCaptioning component, and is produced by a variety of tools and full-service captioning vendors. For more information, see Captions on the Adobe site.

The following are not supported directly in Expression Encoder templates. To use these formats, application authors would have to write parsing logic, as shown in Example 2:

MPEG Part 17 / 3GPP Timed Text. For more information, see ISO/IEC 14496-17:2006 on ISO site.
Other formats that have not realized wide adoption, for example Universal Subtitle Format.
In addition to these formats, other formats for device-specific recorded media (such as DVD encoded tracks) could be cross-purposed for use by streaming/online media.

Rather than build the parsing logic for all these formats into the Silverlight runtime, or choosing just one of these formats to support, the Silverlight design for text captioning at the core level instead makes the TimelineMarkers property of a MediaElement writeable, independently of the value of Source. The format of each TimelineMarker in the collection is very simple: a time value expressed in the format, and the text value of the text for that synchronized caption. The time format for TimelineMarkers is documented as TimelineMarker reference on MSDN. Converting timed text formats to TimelineMarkers form as consumed by the Silverlight core can be done by following any of the following application design patterns:

Authoring the project using Expression Encoder, and using the Expression MediaPlayerTemplate as the media player UI. In this case, Expression produces a Silverlight application that includes assemblies that are generated from code templates. The default build of the project provides a working library that handles all tasks related to timed-text format conversion, from the formats as documented at About Captioning (Expression documentation on MSDN).
The templates of an Expression Encoder project can also be edited, either editing the XAML for the UI by altering the template, or by altering the C# code files that define various aspects of the media player logic, including the timed text format parsers. Then the project can be rebuilt using the desired customizations. Using this technique, it is possible to adapt the code to support timed text formats that are not directly supported in the Expression Encoder project UI.
Using a 3rd party media player implementation that also includes a codebase for processing timed text formats, producing TimelineMarkers, and displaying the captions in the player-specific UI.
Including a library that handles just the format parsing, and using APIs of this library as part of the Silverlight application code-behind.
Writing all logic that is necessary for timed text parsing AND application UI display, and including it all in the main Silverlight application library.

事例

事例 1: Using Expression Encoder and Expression Blend to produce a Silverlight media player project from tool output and templates

By far the simplest technique for incorporating existing timed-text information is to use Microsoft Expression Encoder and the media player templates that an Expression Encoder project produces by default. You can use timed text in any of the following formats: DFXP, SAMI, SRT, SUB, and LRC. Associating a caption file with a media source is done as an "import" operation in the Expression Encoder tool. However, the "import" does not necessarily mean that the timed text file is integrated into the media stream; Silverlight authors have the option to preserve the file separation. This is useful if the application is obtaining timed text from a third party source in real-time, or if Silverlight authors have a production pipeline that makes it difficult to have the captioning ready in time to be encoded in the stream along with the audio-visual source files. For third-party timed text files that are served directly from the third party's HTTP servers, it can be useful to supply a dummy URL in the initial project encoding. The output of the Expression Encoder project parameterizes many of the project settings at the HTML level. This makes it possible to change the URL at any time prior to deployment without having to rebuild the project. The following code is the HTML output of a sample Expression Encoder project. Note the CaptionSources node in the initparams; that is the information item that informs the Expression Encoder templates where to find the timed text file.

     <object data="data:application/x-silverlight," type="application/x-silverlight" width="100%" height="100%">
       <param name="source" value="MediaPlayerTemplate.xap"/>
       <param name="onerror" value="onSilverlightError" />
       <param name="autoUpgrade" value="true" />
       <param name="minRuntimeVersion" value="4.0.50401.0" />
       <param name="enableHtmlAccess" value="true" />
       <param name="enableGPUAcceleration" value="true" />
       <param name="initparams" value='playerSettings = 
         <Playlist>
           <AutoLoad>true</AutoLoad>
           <AutoPlay>true</AutoPlay>
           <DisplayTimeCode>false</DisplayTimeCode>
           <EnableOffline>false</EnableOffline>
           <EnablePopOut>false</EnablePopOut>
           <EnableCaptions>true</EnableCaptions>
           <EnableCachedComposition>true</EnableCachedComposition>
           <StretchNonSquarePixels>NoStretch</StretchNonSquarePixels>
           <StartMuted>false</StartMuted>
           <StartWithPlaylistShowing>false</StartWithPlaylistShowing>
           <Items>
             <PlaylistItem>
             <AudioCodec></AudioCodec>
             <Description></Description>
             <FileSize>2797232</FileSize>
             <IsAdaptiveStreaming>false</IsAdaptiveStreaming>
             <MediaSource>thebutterflyandthebear.wmv</MediaSource>
             <ThumbSource></ThumbSource>
             <Title>thebutterflyandthebear</Title>
             <DRM>false</DRM>
             <VideoCodec>VC1</VideoCodec>
             <FrameRate>30.00012000048</FrameRate>
             <Width>508</Width>
             <Height>384</Height>
             <AspectRatioWidth>4</AspectRatioWidth>
             <AspectRatioHeight>3</AspectRatioHeight>
             <CaptionSources>
               <CaptionSource Language="English" LanguageId="eng" Type="Captions" Location="thebutterflyandthebear.eng.capt.dfxp"/>
             </CaptionSources>
           </PlaylistItem>
         </Items>
      </Playlist>'/>       
   </object>

The templates include a library that handles any parsing requirements for the chosen timed text format, both at the level of getting the basic text and timing into the TimelineMarkers used by the run-time MediaElement, and for preserving a subset of format information that can reasonably be crossmapped from the formatting paradigm of the source (typically HTML/CSS) into the Silverlight text object model of the text element that displays the captions in the running Silverlight application.

The following is a brief description of the procedure for creating a project that incorporates a separate timed text file.

From the initial Expression Encoder screen, select New Project from the File menu.
In the Load a new project dialog, select Silverlight Project.
From the File menu, select Import. Choose the primary media source file the project will use.
In the Text tab, find the listing for the media source file. Click the + icon to the right of the file name. This opens a file dialog.
Choose a timed text file to add to the project.
Build the project. By default the project produces a complete output folder. The folder includes the media player template XAP, the timed text file as a separate file, and additional libraries and XAPs that support the basic template and/or the timed text capabilities.
Optionally, use the features in the Templates tab of Expression Encoder to generate a template copy. You can edit the template copy in other tools such as Expression Blend or Visual Studio, to change the layout or behavior from the default media player template. Template editing can address requirements such as applying a particular branding or "look" to the player user interface.

The following is a screenshot of the Expression Encoder (version 4) interface. The + icon mentioned in Step 4 is highlighted in this screenshot with a red diamond. The Templates tab mentioned in Step 7 is on the right side, top-middle. Note that all tabs of an Expression user interface are dockable; the orientations shown here are the default, but could be in different locations on any given computer or configuration.

Expression Encoder screenshot

事例 2: Code parses timed text; MediaElement handles MarkerReached, displays marker text in application-defined TextBox

This example defines a very simple media player class that includes a display surface, basic controls, and a text display for captions as part of its default template. The usage code for this control in XAML is simple, but only because the majority of the implementation is present in the definition of the media player class.

The following is example usage XAML:

 <local:SimpleMediaPlayerWithTT Width="480" Height="360" CaptionUri="testttml.xml" MediaSourceUri="/xbox.wmv" />

Note the attributes CaptionUri and SimpleMediaPlayerWithTT. Each of these is a custom property of the media control class TTReader. CaptionUri in particular references a URL, in this case a local URL from the same server that serves the Silverlight XAP. The timed text file could come from a different server also, but comes from a local server in this example to conform to the behavior of the test file.

The following is the generic.xaml default template for the media player control. The template is mainly relevant for showing the named elements that are shown in the initialization code.

               <ControlTemplate TargetType="local:SimpleMediaPlayerWithTT">
                   <Border Background="{TemplateBinding Background}"
                           BorderBrush="{TemplateBinding BorderBrush}"
                           BorderThickness="{TemplateBinding BorderThickness}">
                       <Grid x:Name="vroot">
                           <Grid.RowDefinitions>
                               <RowDefinition Height="*"/>
                               <RowDefinition Height="50"/>
                               <RowDefinition Height="80"/>
                           </Grid.RowDefinitions>
                           <MediaElement x:Name="player" AutoPlay="False"/>
                           <StackPanel Orientation="Horizontal" Height="50" Grid.Row="1">
                               <Button x:Name="player_play">Play</Button>
                               <Button x:Name="player_pause">Pause</Button>
                               <Button x:Name="player_stop">Stop</Button>
                           </StackPanel>
                           <ScrollViewer x:Name="scroller" Height="50" Grid.Row="2">
                           <TextBox IsReadOnly="True" x:Name="captions"/>
                           </ScrollViewer>
                       </Grid>
                   </Border>
               </ControlTemplate>

The following is the initialization code that is for general infrastructure. OnApplyTemplate represents the code wiring to the template-generated UI.

   public class SimpleMediaPlayerWithTT : Control
   {
       MediaElement player;
       TextBox captions;
       public SimpleMediaPlayerWithTT()
       {
           this.DefaultStyleKey = typeof(SimpleMediaPlayerWithTT);
       }
       public override void OnApplyTemplate()
       {
           base.OnApplyTemplate();
           player = this.GetTemplateChild("player") as MediaElement;
           captions = this.GetTemplateChild("captions") as TextBox;
           scroller = this.GetTemplateChild("scroller") as ScrollViewer;
           //event hookups and prop inits
           player.MediaOpened += new RoutedEventHandler(OnMediaOpened);
           player.MediaFailed += new EventHandler<ExceptionRoutedEventArgs>(OnMediaFailed);
           player.Source = this.MediaSourceUri;
           player.MarkerReached+=new TimelineMarkerRoutedEventHandler(player_MarkerReached);
           Button player_play = this.GetTemplateChild("player_play") as Button;
           player_play.Click += new RoutedEventHandler(player_play_click);
           Button player_pause = this.GetTemplateChild("player_pause") as Button;
           player_pause.Click += new RoutedEventHandler(player_pause_click);
           Button player_stop = this.GetTemplateChild("player_stop") as Button;
           player_stop.Click += new RoutedEventHandler(player_stop_click);
       }
       // mediaelement in template events
       void OnMediaOpened(object sender, RoutedEventArgs e)
       {
           LoadCaptions(captionUri);
       }
       void OnMediaFailed(object sender, ExceptionRoutedEventArgs e)
       {
       }
       void player_MarkerReached(object sender, TimelineMarkerRoutedEventArgs e)
       {
           captions.SelectedText = e.Marker.Text + "\n";
           scroller.ScrollToVerticalOffset(scroller.ScrollableHeight);
       }
       void player_play_click(object sender, RoutedEventArgs e)
       {
           player.Play();
       }
       void player_pause_click(object sender, RoutedEventArgs e)
       {
           player.Pause();
       }
       void player_stop_click(object sender, RoutedEventArgs e)
       {
           player.Stop();
       }
       // properties
       private Uri captionUri;
       public Uri CaptionUri
       {
           get { return captionUri; }
           set { captionUri = value; }
       }
       private Uri msUri;
       public Uri MediaSourceUri
       {
           get { return msUri; }
           set { msUri = value; }
       }

The following is the logic that is particular to obtaining the separate caption file. Some of this logic is referenced in the preceding template-specific event handlers. This example uses the asynchronous WebClient technique to request the file result of the CaptionUri. Make sure to use AutoPlay=false or some other means to allow time for the caption file to download before attempting to play the media file.

       private void LoadCaptions(Uri captionURL)
       {
           WebClient wc = new WebClient();   // Web Client to download data files
           if (captionURL != null)
           {
               wc.DownloadStringCompleted +=
                   new DownloadStringCompletedEventHandler(OnDownloadStringCompleted);
               wc.DownloadStringAsync(captionURL);
           }
       }
       private void OnDownloadStringCompleted(object sender, DownloadStringCompletedEventArgs e)
       {
           if (!e.Cancelled && e.Error == null && e.Result != "")
           {
               string xml = e.Result.Trim();
               ParseCaptionData(new StringReader(xml));
           }
       }

The actual parsing can be done using a combination of the "XML to Linq" facilities of an optional Silverlight library, and standard .NET Framework string format APIs from the Silverlight core. An implementation is NOT provided here, due to length considerations. TTML supports a number of profiles and capabilities. The basic pattern to follow in the implementation is to obtain the necessary text and timing information, and to pass it to a function that might resemble the following code template. This code template takes the raw information, generates a new TimelineMarker, and adds it to the collection assigned to the active MediaElement as identified by "player" in the application.

       public void AddMediaMarker(string time, string type, string data)
       {
           TimelineMarker marker = new TimelineMarker();
           marker.Time = new TimeSpan(0,0,(Convert.ToInt32(time.Trim())/1000));
           // this logic could vary depending on how time is formatted in the input string; this one assumes raw milliseconds
           marker.Type = type;
           marker.Text = data.Trim();
           player.Markers.Add(marker);
       }

参考リソース

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

Audio and Video Overview
MediaElement Class
TimelineMarker.Time
Accessible Media Project - a reference implementation MediaPlayer control from the Silverlight product team that includes several accessibility features including captioning; note that the codebase might not be updated to Silverlight version 4

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. That application plays media that is expected to have text captioning.
Check that the text area in the textbox shows captions for the media, and that the captions synchronize with media in an expected way.

期待される結果

#2 is true.

SL29: Using Silverlight "List" Controls to Define Blocks that can be Bypassed

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.1 (ブロックスキップ)
- クイックリファレンス 2.4.1 (ブロックスキップ)
- 達成基準 2.4.1 (ブロックスキップ)を理解する

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

SL29 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to use some of the basic user interface objects in Silveright to produce blocks of content that are identified as a "List" to accessibility frameworks and to Silverlight's own tab sequence navigation behavior.

Using the "List" technique results in a tab sequence behavior whereby that element is treated as a single tab stop, even if that element has consituent elements (the list items) that would otherwise be considered additional tab stops in the main tab sequence. In the default key handling, when the user presses the TAB key while focus is on a List, the focus goes to the next element after the List. To focus the items of the list, the user would press the Arrow keys rather than TAB. In the Silverlight programming model for controls, this tab sequence behavior is expressed by the TabNavigation property holding the value of Once. The Silverlight ListBox is a control that reports itself as "List" role, and that has a default TabNavigation.Once value. Thus ListBox as per this technique is a lightweight technique for producing blocks that can be bypassed. It is specifically a lightweight technique because it can be accomplished by writing simple application-level XAML and using only the Silverlight core libraries.

Silverlight also supports more full-featured techniques for producing bypass blocks that are based on common user interface features such as menus or toolbars. However, using toolbars in Silverlight is inherently not as lightweight because the Silverlight core libraries themselves do not include a ready-made toolbar. Silverlight provides a ContextMenu as part of the Silverlight Toolkit extensions, but the behavior of this particular menu does not easily address the bypass block scenario. Silverlight includes all the infrastructure and necessary base classes for defining a toolbar or a menu that could address the bypass block scenario. Many third-party control implementations of menus and toolbars exist, either as part of control packages that are sold by control vendors, or through community mechanisms such as CodePlex or third-party sites that provide free source code. For some examples, see the following:

If application authors use a built-in control such as ListBox where the accessibility framework reported role is not traditionally associated with a navigation role, it is a best practice to set AutomationProperties.Name such that the name informs the user of the purpose of the list control. Otherwise, the role alone leaves this ambiguous. For example, an author might name the list control "Navigation control".

Often the List control itself is focusable. So long as the List control has a visual focus indicator, that behavior might be acceptable. However, it might provide a better user experience to deliberately have the List itself non-focusable, and instead have focus fall to the first List item when focus reaches that region. Otherwise, the List might be perceived as an "extra" tab stop to some users. To enable that behavior, set IsTabStop to false on the List control. The List itself still provides the intended tab navigation behavior, and is still reported and identified to accessibility frameworks and assistive technologies, even when the List container is not focusable. This is shown in Example 1, by setting IsTabStop as part of a Style.

When an accessibility framework presents a List, assistive technologies are generally expected to continue to support use of the same key behavior as the default behavior, and to report to users that the item is a List when it is focused. If assistive technologies use the accessibility framework APIs for navigation, the items in the list are considered child elements. Navigating either by spatial direction (e.g. NAVDIR_RIGHT in MSAA) or sequential direction (e.g. NAVDIR_NEXT in MSAA) skips the list items and goes to the spatial/next peer.

事例

事例 1: Customize the behavior and appearance of a ListBox to construct a navigation control that can be bypassed

In this example, several properties that influence the items presentation behavior of the Silverlight core control ListBox are adjusted to make it suitable for a navigation control. The behavior of this control is that when the tab sequence reaches the control, "next" or spatial navigation continues on to other controls, rather than through the child controls of the list's items/options. This is enabled and properly reported because ListBox reports its accessibility framework role as "List", uses TabNavigation = Once as default (because it is the default, TabNavigation does not have to be set explicitly in the markup). ListBox has default key handling for the arrow keys (to enable traversing the choices in the menu by keyboard-only). The control could also be visually a menu or perhaps other user interface control metaphors, depending on how it is visually templated and composited. Regardless of appearance, the accessibility framework and any assistive technologies based on that framework will treat the control as a "List". This example is templated as a horizontally oriented toolbar-type control. The items in this example are Button controls, but could be templated to not appear quite as button-like, or could instead use another focusable control for the items such as a read-only TextBox.

<UserControl x:Class="TabNavigation.MainPage"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
   <StackPanel x:Name="LayoutRoot" Background="White">
       <ListBox AutomationProperties.Name="Navigation Control">
           <ListBox.ItemsPanel>
               <ItemsPanelTemplate>
                   <StackPanel Orientation="Horizontal"/>
               </ItemsPanelTemplate>
           </ListBox.ItemsPanel>
           <ListBox.ItemContainerStyle>
               <Style TargetType="Control">
                   <Setter Property="IsTabStop" Value="False"/>
               </Style>
           </ListBox.ItemContainerStyle>
           <Button>Home</Button>
           <Button>Search</Button>
           <Button>Tools</Button>
           <Button>Help</Button>
       </ListBox>
   </StackPanel>
   <Button>Button here to show a focusable peer control beyond the list</Button>
</UserControl>

The following is an illustration of what such a control might look like:

Screen shot of a focusable control beyond a list of buttons

This example is shown in operation in the working example of Tab Navigation.

参考リソース

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

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
Press TAB key to traverse typical tab sequence within the Silverlight application. Verify that common areas in the user interface composition ("blocks") that are reporting the List role per this technique can be bypassed without having to tab through each constituent part (the "items/children" of the List).
Verify that the list children are still accessible by keyboard, by using ARROW keys rather than TAB.
Engage an accessibility framework test tool such as UIAVerify. Examine roles in the automation tree, and verify that the List used for bypass behavior reports a combination of name+role that is consistent with the behavior.
Use a screen reader to verify that name and role are reported properly.

期待される結果

#2 and #3 are true, and either #4 OR #5 are true.

SL30: Using Silverlight Control Compositing and AutomationProperties.Name

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

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

SL30 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to properly apply Silverlight control composition techniques that can present text and non-text in UI as part of the same control. This technique explains the consequences that using control composition has on how that control is reported to the accessibility frameworks that Silverlight supports.

Silverlight control composition concepts are relevant either to Silverlight developers who define and package a Silverlight control for use by other Silverlight authors, or for Silverlight application authors that use Silverlight controls in their UI but use the content properties of such controls to include several other elements in a composite layout.

In Silverlight programming and UI definition, Silverlight authors can use control composition to define a parent control that initiates an action. The control can have component parts, such as text and non-text composition pieces that display within the control and have equivalent meaning. Silverlight authors can rely on the text component of the control to provide any text alternative for purposes other than the accessibility framework. However, Silverlight authors should declare alternative text on the control that is specifically consumed by accessibility frameworks, by setting AutomationProperties.Name as an attribute in XAML. In most cases, this text can be the same as the visible text in the control composition, per the definition of 'label' in SC 4.1.2.

Note that this technique does not result in a duplication of text, as explained in H2. This is because the element parts of control composition are either inherently not focusable separately, or can be specified by instance-specific properties to behave as if they cannot be focused. The parts in Silverlight composition are not promoted to the accessibility frameworks as parts of an application-specific UI Automation tree, so that control composition as an implementation detail does not interfere with the usage of controls by Silverlight application authors. The primary source of accessibility-related information is the specific AutomationProperties.Name property as set on the parent control in the composition, which is set by the application author rather than the control author.

The control author does specify the information that is reported to accessibility frameworks as the "ClassName", which is often used by assistive technologies for identification purposes and is appended to any "Name" value. For example, if an application author includes a "Widget" control, and gives it an AutomationProperties.Name value of "Show Map", an assistive technology might identify the element as "Show Map widget". The "Show Map" part comes from the application author code, and the "widget" part comes from the Widget control implementation code.

事例

事例 1: Button is composed with a StackPanel that contains nontext and text content

In this example the TextBlock that goes with the graphic image conveys the text information for non-accessibility purposes. The Button has internal composition that combines text from a non-focusable TextBlock part and an image part. Therefore the "Pause" Text is not promoted to serve as "Name" through built-in Button automation peer logic. The Silverlight application author is responsible for explicitly setting AutomationProperties.Name on the Button so that the text equivalent is available to the accessibility framework. This example shows the XAML UI. The logic, which might be attached to Button with a Click handler, is not shown.

 <Button
   Height="20" Width="50" AutomationProperties.Name="Pause" 
 >
   <StackPanel Orientation="Horizontal" >
     <Image Height="12" Width="12" Source="/icon_pause.png"/>
     <TextBlock Text="Pause"/>
   </StackPanel>
 </Button>

This example is shown in operation in the working example of Button Nontext Text Composition.

事例 2: Button composed, using binding and resource references for strings

This example is similar to Example 1 and produces the same result at run time. This example shows the preferred technique of using the Silverlight data binding and resource features to ensure that the strings for text content and accessibility are the same strings. Also, this gets the strings out of the XAML source and makes them simpler to localize or edit. For more information on using resource strings through binding, see Localizing XAML topic on MSDN.

 <Application.Resources>
  <resx:Resources x:Key="UIResourceStrings" />
 </Application.Resources>
  ...
 <Button
   Height="20" Width="50"
   AutomationProperties.Name="{Binding PauseUIString, Source=UIResourceStrings}" />
 >
   <StackPanel Orientation="Horizontal" >
     <Image Height="12" Width="12" Source="/icon_pause.png"/>
     <TextBlock
       Text="{Binding PauseUIString, Source=UIResourceStrings}"/>
   </StackPanel>
 </Button>

参考リソース

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

検証

Automation tree verifier

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
Use a verification tool that is capable of showing the full automation tree, and an object’s name text alternative as part of the tree. (For example, use UIAVerify or Silverlight Spy; see Resources links.)
Check that the AutomationProperties.Name appears as the Name value for identification in the automation tree, whenever a composite control that has both text and non-text elements is encountered.

期待される結果

#3 is true.

検証

Screen reader

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
Engage the screen reader. With focus inside the Silverlight content area, press TAB to focus to a composite control where both text and non-text elements are present.
Check that the Name as applied to the control instance, along with the class name of the control, is read by the screen reader.

期待される結果

#3 is true.

SL31: Using Silverlight Font Properties to Control Text Presentation

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

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

SL31 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to change the presentation / visual appearance of text, by setting several of the font-specific properties in the Silverlight API. Changing such properties does not change the semantic meaning of the text, nor does it alter the representation of the text that is available to assistive technologies through the Silverlight support of the UIA accessibility framework. By using font properties, it is possible to introduce a wide variety of presentation changes to fonts that do not introduce semantic elements that interfere with an assistive technology's view of text in the Silverlight application. In particular, adjusting font properties will make it possible to avoid any need for use of images of text, yet still provide a wide range of choices for text presentation.

Silverlight font properties exist on all controls, as well as on other text elements that are not true controls. For controls, the font properties apply in any case where the control enables a presentation mode that has enclosed text areas in its layout. By setting Silverlight font properties, it is possible to adjust presentation of font features without changing the structural connotation of that control, or the value of any control-specific property that contains plain-text. For example, the FontSize property can be set on a Paragraph (not a control) or on a Button (a control, and in this case the font size changes apply to any text displayed in the button content area). Font properties are also inheriting properties, meaning that if applying a font property value to a container in a relationship, those font property values can apply to child elements in the relationship. For example, if a FontSize is applied to a RichTextBox, that FontSize value is used by default by all the Paragraph items displayed in the RichTextBox.

Similar to CSS, Silverlight font properties can be grouped as a Style. That Style can be applied to all instances of a text element type (for example to all cases of Paragraph) or specifically referenced as a resource that is only used by certain instances of a text element type. Either way, the Style feature enables the separation of presentation from semantics for text elements, and enables workflows where content authors supply the semantic text and design-oriented authors adjust the related Silverlight styles. For more information on the Silverlight concept of styles, see Control Customization on MSDN.

The following Silverlight font properties are useful to style text and avoid the need for text in images. Links in this list refer to the Control class version of these properties.

The FontFamily property is used to display the code aspect in a monospace font family (specifically, FontFamily="Courier New").
The FontSize property is used to display the text in a larger size.
The FontStyle property is used to display text in italics.
The FontWeight property is used to set how thick or thin characters in text should be displayed.
The FontStretch property is used to control the spacing of letters in text.
The Foreground property is used to display the color of text or text containers.
The Background property can be used to display text on a non-text background.

So long as images of text are avoided, the text within a Silverlight text element can be reported to the UI Automation accessibility framework that Silverlight supports. That text is reported using the same basic text content as is used for semantic text display in the UI. In other words, exposing that text to assistive technologies that use UIA as a framework does not require the Silverlight application author to resort to automation-specific override properties such as AutomationProperties.HelpText; the automation peers for text elements report all necessary text content to automation as a built-in behavior of the text element controls. For more information on UI Automation and text containers, see SL32: Using Silverlight Text Elements for Appropriate Accessibility Role.

CSS versus Silverlight font properties

Related CSS techniques mention that users can override any page-declared CSS styling techniques, by invoking browser-specific features. For example, using Internet Explorer, a user can use Tools / Internet Options, Appearance / Accessibility to override certain classifications of CSS-controlled font properties when displaying HTML documents, or to use a user-specific style sheet for HTML documents. No browser-level equivalent feature exists for user alteration of Silverlight text properties in the Silverlight content area. Instead, application authors could supply controls that enable similar font-property changing behavior, and include those controls in the application-specific user interface. For more information on this technique, see SL13: Providing A Style Switcher To Switch To High Contrast.

Glyphs

Silverlight API includes a related text presentation API Glyphs. Glyphs is intended for specific decorative or niche language-support scenarios. The Glyphs API does not offer as much UIA exposure or the ability to programmatically change typical font properties; the main scenarios for Glyphs are to package migrated text content from document formats, or for purely decorative text in a font that is not commonly found on a user system and only the glyphs actually used in the Unicode string are subsetted into the Glyphs font payload. If addressing the WCAG criteria, authors should avoid using Glyphs API and instead use other text containers such as TextBox, along with a font that is supplied in the application package or known to exist on the end user system.

事例

事例 1: Run time applied font properties, style, and template

This example illustrates applying runtime changes to a font property.

This example has UI in XAML, and logic in C#. The following is the XAML.

<UserControl x:Class="DocumentStructure.MainPage"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
   <UserControl.Resources>
       <Style x:Key="NewStyle" TargetType="Control">
           <Setter Property="FontFamily" Value="Arial"/>
           <Setter Property="FontSize" Value="30"/>
           <Setter Property="Height" Value="40"/>
       </Style>
   </UserControl.Resources>
   <StackPanel x:Name="LayoutRoot" Background="White">
   <RichTextBox IsReadOnly="True" Name="rtb" FontFamily="Algerian" FontSize="20">
           <Paragraph>Call me Ishmael. Some years ago--never mind how long precisely--having little or no money in my purse, 
           and nothing particular to interest me on shore, I thought I would sail about a little 
and see the watery part of the world. It is a way I have of driving off the spleen and 
regulating the circulation. Whenever I find myself growing grim about the mouth; whenever 
it is a damp, drizzly November in my soul; whenever I find myself involuntarily pausing before 
coffin warehouses, and bringing up the rear of every funeral I meet; and especially whenever my 
<Hyperlink NavigateUri="http://en.wiktionary.org/wiki/hypo">hypos</Hyperlink>
get such an upper hand of me, that it requires a strong moral principle to prevent me from deliberately stepping into 
the street, and methodically knocking people's hats off--then, I account it high time to get to sea as soon as I can. 
This is my substitute for pistol and ball. With a philosophical flourish Cato throws himself 
upon his sword; I quietly take to the ship. There is nothing surprising in this. If they but knew it, 
almost all men in their degree, some time or other, cherish very nearly the same 
feelings towards the ocean with me.
           </Paragraph>
           <Paragraph>There now is your
               <Hyperlink 
               NavigateUri="http://en.wikipedia.org/wiki/New_York_Harbor">insular city of the Manhattoes</Hyperlink>
, belted round by wharves as Indian isles by coral reefs--commerce surrounds it 
with her surf. Right and left, the streets take you waterward. Its extreme downtown is the 
battery, where that noble mole is washed by waves, and cooled by breezes, which a few hours 
previous were out of sight of land. Look at the crowds of water-gazers there.
           </Paragraph>
           <Paragraph>Circumambulate the city of a dreamy Sabbath afternoon. 
Go from Corlears Hook to Coenties Slip, and from thence, by Whitehall, northward. What do you see?
--Posted like silent sentinels all around the town, stand thousands upon thousands of mortal men 
fixed in ocean reveries. Some leaning against the spiles; some seated upon the pier-heads; 
some looking over the bulwarks of ships from China; some high aloft in the rigging, as if striving 
to get a still better seaward peep. But these are all landsmen; of week days pent up in lath 
and plaster--tied to counters, nailed to benches, clinched to desks. How 
then is this? Are the green fields gone? What do they here?
           </Paragraph>
       </RichTextBox>
       <Button Name="swapper" Click="swapper_Click" Width="220">Swap styles</Button>
   </StackPanel>
</UserControl>

The following is C# code:

       private void swapper_Click(object sender, RoutedEventArgs e)
       {
           rtb.Style = this.Resources["NewStyle"] as Style;
       }

This example is shown in operation in the working example of Document Structure.

参考リソース

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

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
Test that application of font properties as enabled in application UI changes presentation, but does not change semantic meaning of text.
Close the browser. Repeat the test with an accessibility framework test tool running. There should be no difference in the structure or relationships in the accessibility view beyond the presentation changes.

期待される結果

#2 and #3 are true.

SL32: Using Silverlight Text Elements for Appropriate Accessibility Role

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- クイックリファレンス 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- 達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )を理解する

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

SL32 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to choose a Silverlight text container that provides appropriate behavior and accessibility roles for different types of text content. How those roles interact with existing assistive technologies that are interpreting Silverlight under the larger concept of being an "HTML control part" is also a factor in which Silverlight text container should be used in an application's composition.

Text containers can identified by role to accessibility frameworks, and each type of Silverlight text container uses a different role. Application authors should choose text containers that combine the desired behavior in the user interface with an accessibility role that can be consumed by existing assistive technology implementations.

The Silverlight core libraries define the following classes that are specifically intended as text containers:

UI Automation programmatic access

For programming information that is relevant for how Silverlight application authors produce the application, each text container has its own object model/API. That API is documented on MSDN, specifically for each class TextBox; RichTextBox; TextBlock.) However, rather than using the Silverlight-specific object models, most assistive technologies that are capable of reporting on Silverlight will choose to use UI Automation (or MSAA) to obtain information about the Silverlight elements in general. Text containers within the Silverlight content are identified through UIA accessibility roles. This is because the assistive technologies can use UI Automation to query for ANY relevant text items from the content (and chrome) of the user agent / browser host, not just those that come from Silverlight. That can include the HTML content, items created from scripting, CSS or other plugin-internal object models and so on. In other words, text from Silverlight is integrated into the overall UI Automation view of the user agent host as the top-level application in a platform view. Different types of "text" in a general sense might appear as different UI Automation patterns, as is described below.

TextBox

A TextBox within the Silverlight content area is reported to UI Automation as an Edit role (through MSAA, as Editable Text).

Edit controls are expected to implement the Value pattern for UIA, so that the value of the edit area can be queried or set by a client. Assistive technologies can use this value as a text-string value for screen readers or other purposes.

In typical user interface design, a form with an input field also includes a label or other explanatory text that is proximally close to the input field. In order to maintain proper reading order, the label should typically appear immediately before the input field. This general model should also be used for Silverlight user interface design. For more information on labeling for TextBox controls, see SL26: Using LabeledBy to Associate Labels and Targets in Silverlight.

RichTextBox

A RichTextBox within the Silverlight content area is reported to UI Automation and MSAA as a Document role.

A RichTextBox can either be set to be a read-only control, or left as a read-write control. In the latter case, users can insert a text cursor and make changes to the text. It is more common in Silverlight programming to set the RichTextBox to be read-only; in this scenario the reason for using RichTextBox is because TextBlock did not offer the range of text formatting options that are possible from a RichTextBox.

In UIA, a document is generally expected to support the Text pattern for UI Automation. However, to read the text from a RichTextBox, the assistive technology does not necessarily have to implement code that handles the entirety of the information that the Text pattern reports.

More about the Text pattern

The Text pattern provides APIs to iterate over the internal structure of a document and return text ranges. Each such text range can be queried for specific properties, and can return its plain text string value to UI Automation. Ranges can also be programmatically adjusted by the TextPattern/TextRange APIs. The following is a snippet of a Silverlight-specific UI Automation tree utility to give a general idea of the APIs involved. Note that these are not specifically Silverlight APIs; they are .NET Framework APIs. .NET Framework or Windows Automation APIs are generally what is used for programming a UI Automation client, which runs on a platform runtime rather than the Silverlight runtime. Using the Text pattern is generally what is necessary in order for an assistive technology to obtain a comprehensive view of the "value" for a document role object.

private void FindTheTextPatterns_Click(object sender, RoutedEventArgs e)
{
   if (allSilverlight != null && allSilverlight.Count>0)
   {
       //for simplicity just processing item 0, not assuming more than one SL control
       //on the page because this app controls the page being loaded
       AutomationElementCollection documentsList = allSilverlight[0].FindAll(TreeScope.Descendants,
           new PropertyCondition(AutomationElement.ControlTypeProperty,ControlType.Document)
   );
   for (int j=0; j< documentsList.Count;j++) {
       TextPattern targetTextPattern = 
         documentsList[j].GetCurrentPattern(TextPattern.Pattern) as TextPattern;
       if (targetTextPattern!=null) {
           TextPatternRange tr = targetTextPattern.DocumentRange;
           MessageBox.Show(tr.GetText(Int16.MaxValue));
       }
   }
}
private void GetAllSilverlight()
{
   allSilverlight = this._clientAppRootInstance.FindAll(TreeScope.Descendants,
      new PropertyCondition(AutomationElement.ClassNameProperty, "MicrosoftSilverlight"));
}

MSAA has only limited possibilities for interacting with a Document role, and MSAA code for attempting to do so is not shown.

TextBlock

TextBlock is reported as a Text role in UI Automation. TextBlock has several important characteristics:

A TextBlock is always read-only; only the application author can declare the text, users cannot change it.
A TextBlock is not considered to be a true control in the Silverlight object model (it is not a class derived from Control). The practical implications of this to accessibility scenarios is that a TextBlock is not in the default tab sequence, cannot be manually added to any tab sequence, and cannot be keyboard-focused either programatically or by the user.
TextBlock has a deliberately limited range of block / span formatting options. If the application author desires a wider range of formatting options, for example supporting a "Paragraph" metaphor for blocks of text, a read-only RichTextBox should be used instead.

If the user relies solely on navigating a Silverlight application using the TAB sequence, such navigation will skip over any TextBlock in the interface. This could have implications for how users who use screen readers can interact with the Silverlight content. Screen readers typically read text only from the currently focused element in cases where the user is moving through the TAB sequence or changing focus within the application, and thus cannot read the text from a TextBlock in such a mode. However, most screen readers also have modes for reading text that is not necessarily focusable. These are generally the same modes that screen readers use for a conventional non-interactive HTML document text. For example, some screen readers support a mode that reads text by line, or by word. These modes can read text from a TextBlock.

事例

事例 1: Structure from a container that has non-semantic role in UI Automation, and TextBlock for text

If viewed as a UI Automation tree, the StackPanel and Grid do not exist explicitly in the tree view, because they do not serve a semantic role (only a presentation role). Rather, the tree consists of the items that report some kind of semantic control type. The semantic children of the containers are still reported in the order that they were declared, when viewed as children of the next semantic container upwards in the tree, and despite the containers themselves being abstracted out of the tree. This defines the reading order. This example is a large block of text with intentionally simple formatting, where the only formatting is to represent paragraphs as separate TextBlock elements to support an adaptive layout, but no Run blocks within.

When viewed with assistive technologies that represent the contents, each TextBlock is a control type of Text. Screen readers can use document reading modes such as virtual cursor modes to read the content from each element and each element's content, following the same reading order as is declared in the XAML. For example, in JAWS 12, readers can read out this text container line by line using (Jaws Key)+DownArrow. It is actually JAWS that determines the line length, because the line length otherwise is defined only by the adaptive layout at runtime, which is not reported to UIA.

  <StackPanel x:Name="LayoutRoot" Background="White">
          <TextBlock>Call me Ishmael. Some years ago--never mind how long precisely--
having little or no money in my purse, and
nothing particular to interest me on shore, I thought I would sail about a little 
and see the watery part of the world. It is a way I have of driving off the spleen 
and regulating the circulation. Whenever I find 
myself growing grim about the mouth; whenever it is a damp, drizzly November in 
my soul; whenever I find myself involuntarily pausing before coffin warehouses, 
and bringing up the rear of every funeral I meet;
and especially whenever my hypos get such an upper hand of me, that it requires a strong moral 
principle to prevent me from
deliberately stepping into the street, and methodically knocking people's hats off--then, 
I account it high time to get to sea as
soon as I can. This is my substitute for pistol and ball. With a philosophical flourish Cato 
throws himself 
upon his sword; I quietly take to the ship. There is nothing surprising in this. If they but knew it, 
almost all men in their degree, some time or other, cherish very nearly the same feelings towards the 
ocean with me.
          </TextBlock>
          <TextBlock>There now is your insular city of the Manhattoes, belted round by wharves as Indian isles 
          by coral reefs--
commerce surrounds it with her surf. Right and left, the streets take you waterward. 
Its extreme downtown is the battery, where
that noble mole is washed by waves, and cooled by breezes, which a few hours previous 
were out of sight of land. Look at the crowds of water-gazers there.
          </TextBlock>
          <TextBlock>Circumambulate the city of a dreamy Sabbath afternoon. Go from Corlears Hook 
          to Coenties Slip, and from thence, by Whitehall, northward.
What do you see?--Posted like silent sentinels all around the town, stand thousands 
upon thousands of mortal men fixed in ocean
reveries. Some leaning against the spiles; some seated upon the pier-heads; 
some looking over the bulwarks of ships from China; 
some high aloft in the rigging, as if striving to get a still better seaward peep. 
But these are all landsmen; of week days pent
up in lath and plaster--tied to counters, nailed to benches, clinched to desks. 
How  then is this? Are the green fields gone? What do they here?
          </TextBlock>
  </StackPanel>

事例 2: Text containers and their UIA representation

The following example is intended as sample XAML to view in an accessibility framework viewer, to see the various names, roles, and patterns for obtaining value.

   <StackPanel x:Name="LayoutRoot">
       <TextBox Text="This is a TextBox"/>
       <RichTextBox>
           <Paragraph>This is a RichTextBox.</Paragraph>
       </RichTextBox>
       <TextBlock Text="This is a TextBlock"/>
   </StackPanel>

参考リソース

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

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. To see UI Automation, use Microsoft Windows as platform.
Use a verification tool that is capable of showing the full automation tree. (For example, use UIAVerify or Silverlight Spy; see Resources links.)
Verify that TextBox elements in the Silverlight user interface have the Edit role, that RichTextBox elements have the Document role, and TextBlock has Text role in UI Automation.
Verify that the text content can be programmatically determined by techniques that are appropriate for that role.

期待される結果

#3 and #4 are true.

SL33: Using Well-Formed XAML to Define a Silverlight User Interface

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

達成基準 4.1.1 (構文解析)
- クイックリファレンス 4.1.1 (構文解析)
- 達成基準 4.1.1 (構文解析)を理解する

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

SL33 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to use the characteristics of the XAML language to support basic parsing requirements that both applications and accessibility frameworks rely upon. This technique explains the role of XAML in the overall Silverlight development and application architecture, in particular for defining the elements that make up a Silverlight user interface. This technique also present some basic facts about XAML as a language; more information of this nature is also included in Silverlight Technology Notes.

XAML is a markup language for object instantiation. XAML can be incorporated into a technology such as Silverlight. A specific XAML vocabulary can be defined by a technology such as Silverlight, and the vocabulary can be extended by anyone that provides suitable backing code. For example, a Silverlight application author can define a custom class, and the application author or potentially other Silverlight application authors can use XAML to instantiate instances of the custom class.

XAML has a published language specification.

XAML does not necessarily declare the entirety of the object tree that a Silverlight client runtime loads, but XAML typically declares the majority of the objects/elements that represent the Silverlight application's user interface. The objects and values that are used for accessibility scenarios are often closely related to the standard user interface, and thus accessibility-related properties are typically declared in XAML rather than in code, even though setting the values in code is technically possible.

For more information on XAML in Silverlight, see Silverlight XAML Overview on MSDN.

XAML and XML

XAML is based on XML, and shares many of its language features. Some of the language features that are directly relevant to the stated intent of SC4.1.1 and to 4.1.1 related techniques include:

Well-formedness: The definition of well-formed XAML is the same as the XML definition. XAML processors, including the Silverlight runtime XAML parser, will block loading XAML that is not well formed.
Duplicate attributes: Unless specially configured for scenarios such as design-time support, XAML processors will block loading XAML where elements contain duplicate attributes.
Quote matching: mismatched quote matching for attribute values in XAML constitutes XAML that is not well formed.

Some XAML language features that are analogous to XML but have some technology-specific differences include:

Identifiers: XAML defines a Name directive, which is analogous to xml:id in that Name serves as the unique identifier of an element. However, XAML defines an additional concept of a XAML namescope, which permits a XAML document to contain multiple XAML namescopes as a factoring technique. Thus, identical Name values are permitted in a XAML document so long as each is defined in a separate XAML namescope. XAML namescopes are associated with elements, such that the extent of each XAML namescope is understood by XAML processors.
Schemas and vocabularies: A notable difference between XAML and XML is that a XAML vocabulary is not typically represented in existing XML schema definition formats such as XSD or DTD. XAML includes inheritance and reference features that cannot adequately be expressed in XSD or other existing XML schema representation formats. This affects the "elements are nested according to their specifications" consideration of SC4.1.1. XAML definitely has the ability to enforce nesting restrictions as represented by a XAML vocabulary. However, XAML validity for a vocabulary is deliberately fluid, in order to support extension by user code. XAML validity is determined by a combination of a XAML processor, a XAML concept known as a XAML schema context, and the code that backs the XAML and defines any objects being instantiated as a parsing result. Typically, design time tools such as Microsoft Visual Studio can adequately duplicate the runtime validity characteristics of a XAML vocabulary. Using these tools, application authors can both verify XAML validity as well as receive design-time information for how to correct any XAML validity errors.

XAML parsing and HTML parsing

In the Silverlight implementation, XAML is like HTML in that it is loaded and parsed just-in-time. Silverlight XAML is not precompiled to binary or MSIL (the language-neutral CLR runtime format). Instead,Silverlight XAML is transmitted or stored as plain text, either loose or packaged as resources in a library. Thus Silverlight XAML is human readable as well as machine readable.

However, unlike HTML, Silverlight XAML is only intended to be loaded and interpreted by the Silverlight runtime, rather than multiple possible user agents that each implement an HTML engine. HTML is a language where the behavior is also specified. In contrast, XAML is a language for referencing constructs that are defined in runtime libraries, and the functional specification of the XAML language itself is minimal (intrinsics; language rules; primitive types). Layout, appearance, type-member sets, roles, etc. are all left up to specific frameworks and vocabularies that use XAML. Behavior associated with a given XAML construct is based on type definitions made in a runtime library. For Silverlight XAML, the types are from Silverlight core libraries, but often the definitions come from libraries that are available to the Silverlight runtime as part of an application's packaging for distribution.

XAML is generally speaking strict, and will raise parsing errors if XAML contains elements that are not recognized. Such parsing errors generally present the information in the XAML from resulting in any objects being created, which in turn prevents a Silverlight application from running. This is different from typical (non-xHTML) HTML, where implementations are permitted to contain nonrecognized elements or attributes and ignore them.

事例

事例 1: XAML in design tools for Silverlight

A developer utilizes features in their Silverlight XAML authoring tool to ensure that:

XAML is well formed
XAML is valid according to Silverlight parser and all reference assemblies
XAML Names are unique in namescope
XAML has no duplicate attributes

More about design tools and XAML

Silverlight XAML is able to be loaded by design tools for Silverlight. In the design tool, the XAML is interpreted much like the runtime interprets it, in order to show the visual representation of the Silverlight application. In addition, the design tool might implement design surfaces in which the user interface can be changed, and typically provides a way to save any changes made in the tool back into the loaded XAML.

At design time, tools such as Microsoft Visual Studio or Microsoft Expression might provide opportunities to correct any XAML errors before the Silverlight application is compiled and packaged for deployment. This might be implemented by performing static analysis of the XAML, by forwarding the design tool's own parser errors as it renders the design surface, or by forwarding linking errors that are identified by a precompile step (for example, missing event handlers raise a XAML error from precompile). This behavior is sometimes identified as a design mode behavior in Microsoft documentation and other documentation about Visual Studio or specific tools.

Regardless of how a given XAML file behaves while being interacted with in a design mode, it is the Silverlight runtime XAML parser on each client installation that is the ultimate determinant of whether the XAML is valid or invalid.

事例 2: Silverlight application consumer

A consumer views a Silverlight application that is hosted in an HTML page. If the Silverlight application has valid XAML, the Silverlight content loads, and the fact that the XAML-based UI loaded at all is assurance that:

XAML is well formed
XAML is valid
XAML validity is partially based on correct type mapping of all elements referenced in XAML, according to Silverlight XAML parser and all reference assemblies included by that application
XAML Names are unique in namescope
XAML has no duplicate attributes
XAML-defined properties that are relevant for assistive technology (for example AutomationProperties.Name as described by other Silverlight techniques) are available

参考リソース

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

Silverlight XAML Overview on MSDN

G192: 仕様に完全に準拠する

検証

Pass case

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. That application is known to consume Silverlight XAML.
Verify that the application runs correctly and displays user interface.

期待される結果

#2 is true.

検証

Fail case

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. That application is known to consume Silverlight XAML, and the XAML is known to be deliberately invalid.
Verify that the application did not run.

期待される結果

#2 is true.

Note that it is common that an error message is displayed to users in HTML, which is implemented by handling the JavaScript OnError event emitted by the Silverlight plugin. XAML parse errors are forwarded to JavaScript errors and can be handled in this way. However, it is also possible that the application is production-ready, and deliberately does not expose any JavaScript errors, whether Silverlight managed code errors or not. If seeing the specific error is important, the test might need to be run against a preproduction or debug version of the application.

SL34: Using the Silverlight Default Tab Sequence and Altering Tab Sequences With Properties

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

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

SL34 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to use the default Silverlight tab sequence, or alternatively to apply the options that Silverlight application authors can use for altering the tab sequence. Application authors might alter the tab sequence in cases where the default tab sequence is not desirable for some reason, and those reasons might vary per application or application scenario. The tab sequence can be altered in order to create a meaningful sequence in the tab order, so that assistive technologies that rely on traversal of focusable elements can use and determine the meaningful sequence.

Silverlight uses structured definitions for defining its user interface presentations, where the declaration order is significant because it becomes the structure of the run-time visual tree. The structured definitions also define the layout and presentation structure in most cases. The structured definition concept is described in more detail in Silverlight Technology Notes.

The Silverlight development platform attempts to create an overall system where the logical order of how elements are defined in XAML and code, and then presented in a user interface, will also match a logical tab sequence and logical reading order when presented to the user. In many cases, a Silverlight application author can write an application without necessarily worrying about the tab sequence, can test the tab sequence during a verification and testing phase of development, and will not need to set any specific properties to adjust the tab sequence. As a broad generalization, a Silverlight tab sequence will be constructed so that it traverses elements left to right, and top to bottom, and will behave similarly to how HTML would behave if the HTML analogs of Silverlight elements were constructed and presented in the same way. However, there are specific Silverlight controls that deliberately alter the tab sequence, or whose elements are made keyboard-accessible through a keyboard navigation technique other than TAB. For more information, see Focus Overview on MSDN.

How Silverlight implements tab sequence concepts

The Silverlight programming model defines a Control class that is a base class of many of the practical controls that produce a Silverlight application user interface. One of the behaviors of the Control class is that only a Control can receive keyboard focus as a discrete element within the Silverlight content area.

When a Silverlight application user interface is constructed from the visual tree, a default tab sequence for all Silverlight content is also constructed, using the same principles of order that were used by the visible layout. This default tab sequence is usually adequate as a tab sequence that supports users that press the TAB key to traverse the UI. The same TAB sequence and/or the focusable state of controls is also used by many assistive technologies or modes of assistive technologies to construct the representation of the interface for the Silverlight content.

For cases where developers decide that the default tab sequence is not adequate, the developer can take one of two approaches for changing the tab sequence:

Change other properties of the control where a change to the tab sequence happens as a secondary effect.
Reorder the tab sequence directly.

Changing control properties

Setting the Visibility property of a control to Collapsed causes the control to no longer render in the UI. As a secondary effect, that control is removed from the tab sequence.
Setting the IsEnabled property of a control to false causes the control to no longer be focusable by keyboard or clickable by the mouse. In many cases, the visual appearance of the control changes also, through a theme style. For example, the control may appear as gray rather than black. As a secondary effect, that control is removed from the tab sequence.

Changing specific tab properties

Setting the IsTabStop property of a control to false causes the control to no longer be focusable by keyboard or programmatic focus, and that control is removed from the tab sequence.
Setting the TabIndex property of a control to a specific index causes the control to be inserted at that position in the tab sequence. The default value of TabIndex is Single.MaxValue, therefore any non-default value promotes that control to be first in an otherwise default tab sequence. More typically, authors would specify a TabIndex for any controls that are involved in a deliberate segment of tab order re-ordering.

Tab order and language

Left-to-right is the default only for languages that use left-to-right reading order. For languages that use right-to-left reading order, right-to-left is also the default tab order as implemented by Silverlight runtime behavior. That language preference is declared by the acting CultureInfo. For more information on CultureInfo, see SL27: Using Language/Culture Properties as Exposed by Silverlight Applications and Assistive Technologies.

事例

事例 1: Default tab order, based on ordering in the StackPanel

In this example, a StackPanel has a natural layout order of top-to-bottom, and that will also be the tab order of each StackPanel child element (FirstName, then LastName).

   <StackPanel x:Name="LayoutRoot" Background="White">
       <StackPanel Orientation="Horizontal">
           <TextBlock Name="lbl_FirstName">First name</TextBlock>
           <TextBox AutomationProperties.LabeledBy="{Binding ElementName=lbl_FirstName}" Name="tbFirstName" Width="100"/>
       </StackPanel>
       <StackPanel Orientation="Horizontal">
           <TextBlock Name="lbl_LastName">First name</TextBlock>
           <TextBox AutomationProperties.LabeledBy="{Binding ElementName=lbl_LastName}" Name="tbLastName" Width="100"/>
       </StackPanel>
   </StackPanel>

This example is shown in operation in the working example of Tab Sequence.

事例 2: Tab order, modified by TabIndex

A form is marked up using a data table that includes the fields of the groom in the first column and the fields of the bride in the second column. The order in the content is row by row but the author feels it is more logical for users to navigate the form column by column. This way, all the groom's criteria can be filled in before moving on to the bride's criteria. The TabIndex attributes of the Silverlight elements are used to specify a tab order that navigates column by column. This example specifically illustrates how changing tab order can change the meaningful sequence.

 <UserControl x:Class="TabSequence.MainPage"
 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 >
   <StackPanel x:Name="LayoutRoot" Background="White">
       <TextBlock>he first column contains the search criteria 
 of the groom, the second column the search criteria of 
 of the bride</TextBlock>
       <Grid>
       <Grid.RowDefinitions>
         <RowDefinition/>
         <RowDefinition/>
         <RowDefinition/>
         <RowDefinition/>
       </Grid.RowDefinitions>
       <Grid.ColumnDefinitions>
         <ColumnDefinition/>
         <ColumnDefinition/>
         <ColumnDefinition/>
       </Grid.ColumnDefinitions>
       <TextBlock>Search criteria</TextBlock>
       <TextBlock Grid.Column="1">Groom</TextBlock>
       <TextBlock Grid.Column="2">Bride</TextBlock>
       <TextBlock Grid.Row="1">First name</TextBlock>
       <TextBox Grid.Row="1" Grid.Column="1" TabIndex="1"/>
       <TextBox Grid.Row="1" Grid.Column="2" TabIndex="4"/>
       <TextBlock Grid.Row="2">Last name</TextBlock>
       <TextBox Grid.Row="2" Grid.Column="1" TabIndex="2"/>
       <TextBox Grid.Row="2" Grid.Column="2" TabIndex="5"/>
       <TextBlock Grid.Row="3" >Place of birth</TextBlock>
       <TextBox Grid.Row="3" Grid.Column="1" TabIndex="3"/>
       <TextBox Grid.Row="3" Grid.Column="2" TabIndex="6"/>
       </Grid>
   </StackPanel>
 </UserControl>

This example is shown in operation in the working example of Tab Sequence TabIndex.

事例 3: Tab order, modified by changing runtime Control properties

In this example, a radio button choice in a form controls whether certain other fields in the form are relevant or not relevant. The current radio button selection toggles the IsEnabled property in such fields to enable or disable them based on how the user selected the preceding logical element, which also affects whether the fields appear in the further tab sequence. The following is UI definition in XAML.

<UserControl x:Class="TabSequence.MainPage"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
   <StackPanel x:Name="LayoutRoot" Background="White">
       <TextBlock>Registration</TextBlock>
       <Grid>
       <Grid.RowDefinitions>
         <RowDefinition/>
         <RowDefinition/>
         <RowDefinition/>
         <RowDefinition/>
       </Grid.RowDefinitions>
       <Grid.ColumnDefinitions>
         <ColumnDefinition/>
         <ColumnDefinition/>
         <ColumnDefinition/>
       </Grid.ColumnDefinitions>
           <StackPanel Orientation="Horizontal">
               <RadioButton GroupName="Registration" Checked="RadioButton_CheckedG">Guest</RadioButton>
               <RadioButton GroupName="Registration" Checked="RadioButton_CheckedC">Custom</RadioButton>
           </StackPanel>
               <TextBlock Grid.Row="1">First name</TextBlock>
           <TextBox x:Name="tb_fn" IsEnabled="false" Grid.Row="1" Grid.Column="1" />
           <TextBlock Grid.Row="2">Last name</TextBlock>
           <TextBox  x:Name="tb_ln" IsEnabled="false" Grid.Row="2" Grid.Column="1" />
       </Grid>
   </StackPanel>
</UserControl>

The following is event handler code.

       private void RadioButton_CheckedC(object sender, RoutedEventArgs e)
       {
           tb_fn.IsEnabled = true;
           tb_ln.IsEnabled = true;
       }
       private void RadioButton_CheckedG(object sender, RoutedEventArgs e)
       {
           tb_fn.IsEnabled = false;
           tb_ln.IsEnabled = false;
       }

This example is shown in operation in the working example of Tab Sequence Enabled.

参考リソース

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

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
Engage the screen reader. Press the TAB key to traverse the sequence of elements inside the Silverlight content area.
Verify that the order in which elements are traversed in a tab sequence is also the expected order of the elements as they are presented visually, particularly in such cases where the order of each element is significant per SC 1.3.2.

期待される結果

#3 is true.

SL35: Using the Validation and ValidationSummary APIs to Implement Client Side Forms Validation in Silverlight

適用 (対象)

Microsoft Silverlight, versions 3 and greater
Silverlight managed programming model and Silverlight XAML

これは、次の達成基準に関連する達成方法である:

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

SL35 に関するユーザエージェントサポートノートを参照のこと。Silverlight Technology Notesも参照。

解説

The objective of this technique is to use the Silverlight Validation API. The Validation API associates the validation logic with form input elements that properly support accessible text both for the initial entry and for any error identification and suggestion that is displayed in the user interface.

Application authors can either associate Validation.Errors output with specific UI elements, include an initially hidden ValidationSummary user interface element, or both. The example shown in this technique uses both ValidationSummary and Validation.Errors. The ValidationSummary is the most appropriate technique for providing text feedback after a form submission attempt, because assistive technologies pick it up as a discrete focusable element in the interface representation. The Validation.Errors technique is perhaps a better cognitive user experience for sighted users, because it presents the specific error suggestions in closer proximity to the input items that are in error.

This technique relies on several Silverlight features: AutomationProperties, the Name property for identifying specific UI elements, the Validation and ValidationSummary API, the ElementName variation of Silverlight data binding, and the general behavior of TextBox elements.

Contrast for validation states of the Label control

Silverlight version 4's default visual styles have a bug where the colors used to indicate an invalid field entry by changing the color of the foreground text do not satisfy the 4.5:1 contrast ratio per SC 1.4.1. To correct for this visual bug, application authors should copy the control template for the Label control, and adjust the color used for the validation state. This is shown in Example 1; the resource "LabelStyle1" was generated by copying the default Label style using Microsoft Expression Blend. Then, the value was changed in the copied template, and the changed template was referenced and included in the application. The specific changed line is indicated by a comment in the Example 1 sample markup.

事例

事例 1: Two form fields with validation on Submit, and an error identification/suggestion system and UI on the client side

In this example, the form fields correspond to a data object that implements a view model. Silverlight uses the view model and data annotations to generate some of its UI, notably the names of the fields are bound to the original view model names from the data. The ValidationSummary API is defined in a "Client SDK" library System.Windows.Controls.Data.Input.dll, which is included as part of the project and the distributable.

This example has a UI defined in XAML and logic defined in C#. The following is the XAML UI.

<UserControl x:Class="AccessibleValidation.MainPage"
 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 xmlns:sdk="http://schemas.microsoft.com/winfx/2006/xaml/presentation/sdk">
<UserControl.Resources>
 <Style x:Key="LabelStyle1" TargetType="sdk:Label">
 <Setter Property="IsTabStop" Value="False"/>
 <Setter Property="HorizontalContentAlignment" Value="Left"/>
 <Setter Property="Template">
  <Setter.Value>
   <ControlTemplate TargetType="sdk:Label">
    <Grid>
     <VisualStateManager.VisualStateGroups>
      <VisualStateGroup x:Name="CommonStates">
       <VisualState x:Name="Normal"/>
       <VisualState x:Name="Disabled"/>
      </VisualStateGroup>
      <VisualStateGroup x:Name="ValidationStates">
       <VisualState x:Name="Valid"/>
       <VisualState x:Name="Invalid">
        <Storyboard>
         <ColorAnimation Duration="0" To="#FFF00000"
         Storyboard.TargetProperty="(Control.Foreground).(SolidColorBrush.Color)"
         Storyboard.TargetName="ContentControl" d:IsOptimized="True"/>
         //above is the line where color was adjusted from default Red to FFF00000, 
         //to satisfy the 4.5:1 contrast requirement
        </Storyboard>
       </VisualState>
      </VisualStateGroup>
      <VisualStateGroup x:Name="RequiredStates">
       <VisualState x:Name="NotRequired"/>
       <VisualState x:Name="Required">
         <Storyboard>
          <ObjectAnimationUsingKeyFrames Duration="0" 
          Storyboard.TargetProperty="FontWeight" 
          Storyboard.TargetName="ContentControl">
           <DiscreteObjectKeyFrame KeyTime="0" Value="SemiBold"/>
          </ObjectAnimationUsingKeyFrames>
         </Storyboard>
        </VisualState>
       </VisualStateGroup>
      </VisualStateManager.VisualStateGroups>
      <Border BorderBrush="{TemplateBinding BorderBrush}" 
      BorderThickness="{TemplateBinding BorderThickness}" Background="{TemplateBinding Background}" 
      CornerRadius="2" Padding="{TemplateBinding Padding}">
       <ContentControl x:Name="ContentControl" Cursor="{TemplateBinding Cursor}" 
         ContentTemplate="{TemplateBinding ContentTemplate}" Content="{TemplateBinding Content}" 
         Foreground="{TemplateBinding Foreground}" FontWeight="{TemplateBinding FontWeight}"
         FontStretch="{TemplateBinding FontStretch}" FontSize="{TemplateBinding FontSize}" 
         FontFamily="{TemplateBinding FontFamily}" HorizontalAlignment="{TemplateBinding HorizontalAlignment}" 
         HorizontalContentAlignment="{TemplateBinding HorizontalContentAlignment}"
         IsTabStop="False" VerticalAlignment="{TemplateBinding VerticalAlignment}" 
         VerticalContentAlignment="{TemplateBinding VerticalContentAlignment}"/>
      </Border>
     </Grid>
    </ControlTemplate>
   </Setter.Value>
  </Setter>
 </Style>
</UserControl.Resources>
 <Grid x:Name="LayoutRoot" Background="White" Margin="10">
   <Grid.RowDefinitions>
     <RowDefinition Height="Auto"/>
     <RowDefinition Height="Auto"/>
     <RowDefinition Height="Auto"/>
     <RowDefinition Height="Auto"/>
     <RowDefinition Height="Auto"/>
   </Grid.RowDefinitions>
   <Grid.ColumnDefinitions>
     <ColumnDefinition Width="Auto"/>
     <ColumnDefinition Width="200"/>
     <ColumnDefinition Width="Auto"/>
   </Grid.ColumnDefinitions>
   <TextBlock Text="Validating Form" FontSize="16" FontWeight="Bold"
     Grid.Column="1" HorizontalAlignment="Center" />
   <sdk:ValidationSummary x:Name="ErrorSummary" IsTabStop="True"
     Grid.Row="1" Grid.ColumnSpan="2" Margin="3" />
   <sdk:Label x:Name="NameLabel" Target="{Binding ElementName=NameTextBox}"
     Grid.Row="2" Margin="3" HorizontalAlignment="Right" Style="{StaticResource LabelStyle1}"/>    
   <TextBox x:Name="NameTextBox" 
     AutomationProperties.Name="{Binding Content, ElementName=NameLabel}"
     Text="{Binding Name, Mode=TwoWay, UpdateSourceTrigger=Explicit, 
     NotifyOnValidationError=True, ValidatesOnExceptions=True}"
     Grid.Column="1" Grid.Row="2" Margin="3" />
   <sdk:DescriptionViewer Target="{Binding ElementName=NameTextBox}" 
     Grid.Column="2" Grid.Row="2" />
   <sdk:Label x:Name="AgeLabel" Target="{Binding ElementName=AgeTextBox}"
     Grid.Row="3" Margin="3" HorizontalAlignment="Right" Style="{StaticResource LabelStyle1}"/>
   <TextBox x:Name="AgeTextBox" 
     AutomationProperties.Name="{Binding Content, ElementName=AgeLabel}" 
     Text="{Binding Age, Mode=TwoWay, UpdateSourceTrigger=Explicit, 
     NotifyOnValidationError=True, ValidatesOnExceptions=True}"  
     Grid.Column="1" Grid.Row="3" Margin="3" />
   <sdk:DescriptionViewer Target="{Binding ElementName=AgeTextBox}" 
     Grid.Column="2" Grid.Row="3" />
   <Button x:Name="SubmitButton" Content="Submit" Click="SubmitButton_Click"
     Grid.Column="1" Grid.Row="4" Width="50" Margin="3" />
 </Grid>
</UserControl>

The following is the C# logic for the page. Note the call to Focus in the logic; many assistive technologies use focus to determine what area of the interface to report to the user. If code calls Focus to reference the error summary once it is completed, the assistive technology can report the error summary immediately.

       public MainPage()
       {
           InitializeComponent();
           LayoutRoot.DataContext = new Product();
       }
       // Commits text box values when the user presses ENTER.
       private void TextBox_KeyDown(object sender, 
           System.Windows.Input.KeyEventArgs e)
       {
           if (e.Key == System.Windows.Input.Key.Enter) (sender as TextBox)
               .GetBindingExpression(TextBox.TextProperty).UpdateSource();
       }
       private void SubmitButton_Click(object sender, System.Windows.RoutedEventArgs e)
       {
           NameTextBox.GetBindingExpression(TextBox.TextProperty).UpdateSource();
           AgeTextBox.GetBindingExpression(TextBox.TextProperty).UpdateSource();
           if (ErrorSummary.Errors.Count > 0) ErrorSummary.Focus();
           }

The following is the data class. Note how much of the validation logic is defined within this view model, rather than as part of Silverlight UI logic.

  public class Product 
   {
       private string nameValue;
       private const string nameMessage = "Must be 10 characters or less.";
       [Display(Name = "Username", Description = "Required. " + nameMessage)]
       [StringLength(10, ErrorMessage = nameMessage)]
       [Required(ErrorMessage = "Required.")]
       public string Name
       {
           get { return nameValue; }
           set
           {
               if (nameValue != value)
               {
                   Validator.ValidateProperty(value, new ValidationContext(
                       this, null, null) { MemberName = "Name" });
                   nameValue = value;
               }
           }
       }
       private string ageValue;
       private const string ageMessage = "Must be in the 5 to 120 range.";
       [Display(Description = ageMessage)]
       [Range(5, 120, ErrorMessage = ageMessage)]
       [RegularExpression("\\d*", ErrorMessage = "Must be a number.")]
       public string Age
       {
           get { return ageValue; }
           set
           {
               if (ageValue != value)
               {
                   Validator.ValidateProperty(value, new ValidationContext(
                       this, null, null) { MemberName = "Age" });
                   ageValue = value;
               }
           }
       }

The following image is a screen shot of this simple UI, after two invalid values are entered in the form and Submit is activated:

Form with invalid values

The following image is a screen shot of the UIAVerify tree view of this same application. Note the "Text" role items that appear as adjacent peer elements, which describe the validation errors. This Text is actually coming from sdk:DescriptionViewer, and in the visible UI in the screenshot is not currently visible. This text would be visible if any of the following occurs:

the user hovers the mouse over the red triangle in the input field corner
the user hovers over the "info i" icon
the user clicks (or tabs to) the relevant field, which focuses it

UIAVerify tree view of form with invalid values

This example is shown in operation in the working example of Accessible Validation.

Validation style for Label controls

The default validation style for the Invalid state of Label does not have adequate contrast by default. Application authors can restyle Label with a new template that has a 4.5:1 contrast.

参考リソース

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

SCR32: クライアントサイドのバリデーションを提供し、DOM を介してエラーテキストを追加する

検証

手順

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. The application is expected to contain form fields, and a Submit pattern for form interaction as described in SL10: Implementing a Submit-Form Pattern in Silverlight.
Navigate through the items of a form until an editable field is read. Enter a value that triggers the validation.
Navigate to Submit button and activate it to attempt to submit the form.
Verify that a Validation Summary now appears, and is focusable.
Verify that the Validation Summary provides enough information to correct any error.
Navigate back to input elements that have validation issues. Correct the errors as suggested.
Tab to Submit button. Press ENTER to resubmit.
Verify that Validation Summary is no longer displayed and that the screen reader does not focus to/read any further validation information.

期待される結果

#4, #5, and #8 are true.

11. PDFの達成方法

PDF テクノロジーノート

イントロダクション

Portable Document Format (PDF) は、文書の作成に使用したアプリケーションソフトウェア、ハードウェアおよびオペレーティングシステムや、表示または印刷に使用する出力デバイスに依存せずに文書を表示できるファイル形式である。PDF ファイルは、信頼性が高くデバイスに依存しない方法で、文書内のページの表示を指定する。PDF 仕様は、1993 年に Adobe Systems によって一般公開向けの標準として発表された。2008 年 1 月には、PDF 1.7 が ISO 規格 (ISO 32000-1)[ISO32000] になった。

アクセシビリティについては、2012 年 7 月に ISO 規格となり、2014 年に改正された PDF/UA (ユニバーサルアクセシビリティ) に規定されている (ISO 14289-1:2014 (PDF/UA (ISO 14289-1:2014)を参照)。PDF/UA は、テクニック (ハウツー) 仕様を示すものではなく、よりアクセシブルな PDF を作成するための一連のガイドラインを提供することを目的としたものである。この仕様では、必須のコンポーネントと禁止されているコンポーネントを示すとともに、障害のある人を含め、可能な限り幅広い人々がファイルを利用できるようにすること目的に、それらのコンポーネントを PDF ファイルに含めるか否かを規定する条件について説明している。それらのコンポーネントを PDF ストリームに含めるための機構は、個々の開発者、PDF 作成者または PDF 表示エージェントの裁量に任されている。PDF/UA は、適合するリーダーの動作を規定するルールも指定している。

PDF のアクセシビリティサポート

PDF には、障害のある利用者のための文書のアクセシビリティをサポートするいくつかの機能が含まれている。このサポートの核心は、論理構造およびタグ付き PDF を通じて、コンテンツの外観またはレイアウトに依存せずに PDF 文書内のコンテンツの論理的な順序を決定できることにある。アプリケーションでは、階層構造をトラバースして各ノードのコンテンツを表示することにより、文書のコンテンツを抽出して障害のある利用者に提示することができる。この理由から、PDF ファイルの作成者は、階層構造を利用して文書内のすべての情報を参照できるようにしなければならない。

論理構造

PDF の論理構造機能 (PDF 1.3 で導入) は、文書のコンテンツに関する構造情報を PDF ファイルに組み込むための機構を提供する。このような情報の例としては、章、見出し、段落、セクションなどの文書の編成や、図、表、脚注などの特殊エレメント情報がある。論理構造機能は拡張可能であり、どのような構造情報を組み込んで、それをどのように表示するかは、PDF ファイルを作成するアプリケーションが選択できる。一方で、PDF 利用者は作成側の構造上の仕組みを知らなくてもファイル内を移動できる。

PDF の論理構造の基本的な機能は、HTML、SGML、XML などの標準的な文書マークアップ言語と共通している。文書の論理構造は、辞書オブジェクトとしての構造エレメントの階層として表される。他のマークアップ言語の構造エレメントと同様に、PDF の構造エレメントにはコンテンツと属性を持たせることができる。PDF では、HTML、SGML および XML でのテキストの役割を、レンダリングされた文書コンテンツが担っている。

PDF 文書の論理構造は、視覚的に認識できるコンテンツとは別個に保存され、相互にポインタで結ばれている。このように分けられているため、論理エレメントの順序と階層構造を、文書のページ上のグラフィックオブジェクトの順序と位置から完全に独立して扱うことができる。

文書の論理構造は、構造階層または構造ツリーと呼ばれる、オブジェクトの階層によって記述される。この階層のルートにあるのが、構造ツリールートと呼ばれる辞書オブジェクトであり、文書カタログの StructTreeRoot エントリによって指定することができる。PDF 1.7 (ISO 32000-1) の節 14.7.2 ("Structure Hierarchy") を参照すると、表 322 に構造ツリールート辞書内のエントリが示されている。K エントリは、構造エレメントである、構造ツリールートの直接の子を指定する。

タグ付き PDF

タグ付き PDF (PDF 1.4) は、PDF をスタイル化して使用するためのものであり、PDF の論理構造フレームワーク上に構築される。タグ付き PDF では一連の標準的な構造タイプと属性が定義され、ページのコンテンツ (テキスト、グラフィックおよび画像) を抽出して他の目的に再利用することができる。これは、次のような操作を行うためのツールで使用することを意図している。

単純にテキストとグラフィックを抽出して、他のアプリケーションに貼り付ける。
元のレイアウトとはサイズが異なるページに合わせて、テキストおよび関連するグラフィックを自動的にリフローする。
検索、インデックス付け、スペルチェックなどの目的でテキストを処理する。
文書構造と基本的なスタイル情報を保持しながら、他の一般的なファイル形式 (HTML、XML、RTF など) に変換する。
支援技術に依存する利用者がコンテンツを操作できるようにする。

PDF ファイルの作成とアクセシビリティ

PDF ファイルはアプリケーションプログラムによって直接作成することも、間接的に他のファイル形式や画像モデルから変換して作成することもできる。さらに、アクセシビリティを確保するために PDF ファイルの検査、確認および修復を行うツールが用意されている。以下の各セクションでは、このような用途で一般的に使用される、代表的なアプリケーションやツールのリストを示す。

ただし、これらのリストは網羅的なものではなく、また特定のアプリケーションやツールを支持するものでもない。これらのリストは、WCAG ワーキンググループが PDF 文書の作成テクニックを検討し公表した時点で、広範に使用されていたツールを例示するにすぎない。あらゆるソフトウェアと同様に、アプリケーションによる PDF アクセシビリティのサポートは、バージョンの違い、特定の PDF 文書の書式要件またはアプリケーションの実際の使用方法によって異なる。つまり、タグなどを適切に作成するには、各種のツールを正しく使用しなければならない。

一般的に、古いツールよりも新しいツールのほうが、優れた機能を提供する。ツールによる PDF のアクセシビリティサポートに関する正式な情報は、そのツールのベンダーから得られる。

PDF ファイルを生成する

多くのアプリケーションが PDF ファイルを直接生成でき、また一部のアプリケーションは直接インポートすることもできる。画像モデルやインタラクティブな文書交換機能を含む、PDF のすべての機能をアプリケーションで利用できるため、この直接的なアプローチが望ましい方法である。これに対して、PDF を直接生成しないアプリケーションでは、PDF 出力が間接的に行われる。間接的な方法としては、主に次の二つがある。

Microsoft® Windows® の GDI や Apple Mac OS の QuickDraw などのアプリケーションプログラミングインターフェイス (API) を呼び出すことで、アプリケーションが印刷可能な出力を記述する。プリンタードライバーと呼ばれるソフトウェアコンポーネントがこれらの呼び出しをインターセプトして解釈し、PDF 形式の出力を生成する。
アプリケーションが、印刷可能な出力を他のファイル形式 (PostScript、PCL、HPGL、DVI など) で直接生成し、それが別の変換プログラムによって PDF に変換される。

これらの間接的な方法を使用すれば既存のアプリケーションから簡単に PDF 出力が得られるが、この方法によって作成される PDF ファイルでは、文書のセマンティックを明らかにする高度な PDF 画像モデルが十分に活用されない場合がある。この原因は、アプリケーションの API 呼び出しまたは中間物としての出力ファイルで具現化される情報では、目的の結果が低いレベルでしか記述されていないためである。元のアプリケーションで維持されていた高度な情報は失われ、プリンタードライバーや変換装置でその情報を利用することができない。

例えば、プリンタードライバーまたは変換装置では正確な視覚的出力が行われるため、PDF 出力の作成時に、文書のセマンティックに関する情報がまったく送信されないか無視される場合がある。その結果、見出しが正しくタグ付けされなかったり、リンクテキストとリンクオブジェクトが関連付けされなかったりする。タグ付けされた最良の出力を生成するために、ツールをどう用いればよいのかを理解するため、PDF オーサリングツールのベンダーに問い合わせのこと。

アクセシビリティがサポートされている PDF オーサリングツール

Adobe Acrobat の PDFMaker - PDFMaker は Adobe Acrobat に含まれており、Microsoft Office、AutoCAD、Lotus Notes などの多数のビジネスアプリケーションに、コンテンツを元の形式からタグ付き PDF に変換するためのマクロを追加する。
Adobe FrameMaker - Adobe Systems が提供する DTP アプリケーション。タグ付き PDF が直接エクスポートされ、代替テキストによる記述もサポートされている。
Adobe InDesign - Adobe Systems が提供するページレイアウトおよび DTP アプリケーション。タグ付き PDF が直接エクスポートされ、代替テキストによる記述もサポートされている。
Adobe LiveCycle Designer - Adobe Systems が提供する Windows ベースのフォームデザインアプリケーション。タグ付き PDF インタラクティブフォームが直接エクスポートされ、代替テキストによる記述もサポートされている。スタンドアロン、または Acrobat Pro からの起動が可能。
LibreOffice - The Document Foundation が提供するオープンソースのワードプロセッシングソフトウェア。タグ付き PDF をエクスポートできる。
Lotus Symphony Documents - IBM が提供するオープンソースのワードプロセッシングソフトウェア。タグ付き PDF をエクスポートできる。
Microsoft® Word - Microsoft Corporation が提供するワードプロセッシングソフトウェア。XPS または PDF として保存するユーティリティによってタグ付き PDF をエクスポートできる。
OpenOffice.org Writer - Sun Microsystems Inc. が提供するオープンソースのワードプロセッシングソフトウェア。PDF としてエクスポートするユーティリティによってタグ付き PDF をエクスポートできる。
Netcentric Technologies が提供する CommonLook Office for Microsoft Office は、Microsoft® Word と PowerPoint のアドインであり、タグ付き PDF 文書を作成できる。CommonLook Office はコンテンツ作成者が Microsoft Word および PowerPoint の環境でアクセシビリティテストを実行し、アクセシビリティに関する問題を修正できるツールを備えている。
Xenos Axess™ for Accessible Statements - この PDF ソフトウェアを組織の既存のエンタープライズコンテンツマネジメント (ECM) インフラストラクチャと統合することで、大量の印刷ストリームをキャプチャし、タグ付き PDF に自動的に変換できる。
WordPerfect® Office - Corel が提供するワードプロセッシングソフトウェア。タグ付き PDF 文書の作成、マークアップおよび共有に使用できる。
Microsoft Office 10 - デスクトップオフィスアプリケーションのスイート。タグ付き PDF を作成できる。

注記: タグ付き PDF ファイルの作成がサポートされていないツールがあるため、様々な PDF 作成ツールの中から選択する場合には注意が必要である。

アクセシビリティのチェックと修復

Adobe Acrobat Pro: Adobe Acrobat Pro は、PDF ファイルの作成と編集を行うアプリケーションである。このアプリケーションには、タグパネルを通じた構造ルートのアクセス機能、順序パネルを通じて読み上げ順序を直接操作する機能、組み込みのアクセシビリティチェッカー、PDF 文書のアクセシビリティを評価および修復するグラフィック機構である TouchUp 読み上げ順序ツールなど、PDF ファイルのアクセシビリティを評価および修復するための多数のツールが含まれている。

Commonlook™ PDF: Commonlook PDF は Netcentric Technologies が提供する Adobe Acrobat Pro 用プラグインである。CommonLook PDF は、画像、テーブル、フォームおよびその他の非テキストオブジェクトに対する適切なタグ付けを含め、アクセシビリティに関する最も一般的な問題の特定、報告および修正を支援する。

API 検査ツール

aDesigner - Eclipse Foundation が提供する障害シミュレーター。視覚に障害のある利用者にとってアクセシブルで使いやすいコンテンツを設計することができる。
inspect32 - Microsoft Windows Software Development Kit (SDK) に含まれており、開発者やテスト担当者が UI コンポーネントのアクセシブルプロパティを調べることができる。
PDDOMView - Acrobat_Accessibility_9.1.zip 内にあり、Accessibility API Reference 文書で説明されている、アクセシビリティインターフェイスの Windows クライアントが使用できるファイルが含まれている。
UISpy - Microsoft Windows Software Development Kit (SDK) に含まれており、開発者やテスト担当者がアプリケーションのユーザインターフェイス (UI) エレメントを表示し、操作することができる。

ユーザエージェント

アクセシビリティがサポートされている PDF ユーザエージェントには次のものがある。

Adobe Acrobat Pro - Adobe Systems が提供する PDF オーサリングツール、エディターおよびビューアー。Windows プラットフォームの MSAA デバイスと互換性がある。テキスト読み上げ (Read Out Loud)、ハイコントラストディスプレイ、大型文字ディスプレイのリフロー、自動スクロール、アクセシビリティのフルチェック、アクセシビリティのクイックチェック、TouchUp 読み上げ順序ツール、アクセシビリティセットアップアシスタントなど、多数のアクセシビリティ機能が組み込まれている。
Adobe Reader – Adobe Systems が無料で配布している PDF ビューアー。Windows プラットフォームの MSAA デバイスと互換性がある。テキスト読み上げ (Read Out Loud)、ハイコントラストディスプレイ、大型文字ディスプレイのリフロー、自動スクロール、アクセシビリティのクイックチェック、アクセシビリティセットアップアシスタントなど、多数のアクセシビリティ機能が組み込まれている。
Kurzweil 3000™ - Kurzweil Educational Systems® が提供する、読み書きおよび学習のための総合的なソフトウェアソリューション。テキスト読み上げ機能によって PDF ファイルが読み上げられる。

Adobe Reader および Acrobat Support によるアクセシビリティ API のサポート

Adobe は、PDF ファイルのコンテンツをスクリーンリーダーなどの支援技術で利用できる方法を提供している。

Microsoft® Windows® オペレーティングシステムでは、Acrobat および Adobe Reader は、PDF コンテンツを Component Object Model (COM) オブジェクトとしてエクスポートする。スクリーンリーダーなどのアクセシビリティアプリケーションは、Acrobat または Adobe Reader とのインターフェイスを次の二つの方法でとることができる。
- Acrobat または Adobe Reader でエクスポートされた MSAA オブジェクトを使用して、Microsoft Active Accessibility (MSAA) を通じてアクセスする。
- Document Object Model (DOM) と呼ばれる PDF 文書の内部構造を参照できる、エクスポートされた COM オブジェクトを通じて直接アクセスする。
UNIX® プラットフォームでは、Adobe Reader は Gnome アクセシビリティアーキテクチャをサポートしている。C ベースのアクセシビリティツールキット (ATK) インターフェイスを利用できる。

DOM と MSAA の両モデルは関連しており、開発者はいずれかまたは両方を使用できる。Acrobat では、PDF ファイルウィンドウ内で発生する注目すべきイベントに関する通知が、アクセシビリティクライアントに対して発行される。またアクセシビリティクライアントからの要求に対する応答が行われる。Acrobat および Reader の最新バージョンでは、アクセシビリティインターフェイスに対するサポートが強化されている。

Acrobat/Reader 5.0 以降では MSAA インターフェイスがサポートされている。
Acrobat/Reader 6.0 以降では、PDF DOM を表すダイレクト COM オブジェクトを通じて、基盤になっている PDF 構造に関する情報を参照できる。DOM アクセシビリティインターフェイスでは、より広範なアクセスが可能になっている。
Acrobat/Reader 7.0 以降では、ATK および拡張 DOM サポートを利用できる。
Linux®、Solaris™、AIX® および HP-UX バージョンの Adobe Reader では、C ベースの ATK インターフェイスが実装されているため、スクリーンリーダー、スクリーン拡大鏡、オンスクリーンキーボードを使用して、アクセシブルなアプリケーションについて Accessibility Technology - Service Providers Interface (AT-SPI) レジストリに対するクエリを行うことができる。
DOM が拡張されたことで、カーソル、選択およびフォーカスのサポートが強化され、新しいインターフェイスである IPDDomDocument、ISelectText および IPDDomNodeExt が提供されている。

支援技術によるサポート

JAWS 12 for Windows - Freedom Scientific が提供するスクリーンリーダー。PDF のサポートは JAWS バージョン 4 から開始されている。
MAGic 11 - Freedom Scientific が提供するスクリーン拡大鏡。
NVDA 2011.1 - NonVisual Desktop Access: NV Access が配布するオープンソースのスクリーンリーダー。NVDA では、合成音声と Braille を通じたフィードバックによって、全盲または視覚に障害のある人が Windows オペレーティングシステムや多数のサードパーティアプリケーションにアクセスして操作できる。
Supernova Access Suite 12.02 – Dolphin が提供する、拡大表示、音声、Braille サポートを利用できるフルスクリーンのリーダー。PDF のサポートは HAL バージョン 5 から開始されている。
System Access To Go - Serotek Corporation が提供するスクリーンリーダー。
VoiceOver - Mac OS X v10.6 Snow Leopard 用のスクリーンリーダー。
Window-Eyes 7.2 - GW Micro が提供するスクリーンリーダー。Window-Eyes は、Window-Eyes 4.2 で PDF ファイルのサポートを最初に提供したスクリーンリーダーである。
ZoomText 9.1 - Ai Squared が提供するスクリーン拡大鏡およびスクリーンリーダー。Adobe Acrobat および Reader がサポートされている。
- AppReader と DocReader の両方を使用することで PDF 文書の表示が可能 (特別な設定は不要)
- すべての Windows オペレーティングシステムで PDF 文書の表示が可能 (特別な設定は不要)
- AppReader および DocReader は Adobe Reader からすぐに起動可能
- PDF 文書を高い精度でページングの遅延なく表示可能
- Internet Explorer で PDF 文書を表示可能 (Adobe Reader プラグインを使用)
- 特別な Adobe Reader 設定がなくても表示の最適化が可能

PDF1: PDF 文書の Alt エントリによって画像にテキストによる代替を適用する

適用 (対象)

画像が含まれているタグ付き PDF 文書

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

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

PDF1 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法の目的は、タグのプロパティリストにある /Alt エントリを通じて、画像にテキストによる代替を提供することである。これは通常、PDF のオーサリングツールを使用して行う。

PDF 文書は、テキストに自然に変換されない画像、数式およびその他の項目について代替の説明を加えることで拡張される。実際に、アクセシビリティのためにはこのようなテキストによる代替が必要になる。代替の説明は、人間が読み取ることができるテキストであり、視覚障害のある利用者のためにテキスト読み上げ技術によって音声化できる。

コンテンツを理解するうえで重要な語句が画像に含まれている場合は、テキストによる代替にそれらの語句を含めるべきである。それによって、代替が画像を正確に表すようになる。この場合、必ずしも画像自体の視覚的な特性を示す必要はなく、画像と同じ意味を表すことが必要である。

事例

事例 1: Adobe Acrobat 9 Pro の TouchUp オブジェクトツールを使用して、画像に /Alt エントリを追加する

この事例は Adobe Acrobat Pro の場合を示している。同様の機能を実行するソフトウェアツールは他にも存在する。他のソフトウェアツールのリストについては、「アクセシビリティがサポートされている PDF オーサリングツール」を参照のこと。

ツール >高度な編集 > TouchUp オブジェクトツールを選択する。
画像のコンテキストメニューから［プロパティ］を選択する。
TouchUp のプロパティダイアログボックスで［タグ］タブを選択する。
［タグ］パネルで、［代替テキスト］テキストボックスにテキストによる代替を入力する。

この事例のサンプルが、画像に /Alt エントリを追加したサンプル: 英語 (PDF ファイル) にある。

事例 2: Adobe Acrobat 9 Pro の TouchUp 読み上げ順序ツールを使用して、画像に /Alt エントリを追加する

ツール > 高度な編集 > TouchUp 読み上げ順序ツールを選択する。
TouchUp 読み上げ順序ダイアログボックスが表示される。
画像を右クリックし、［代替テキストを編集］を選択する。
代替テキストダイアログボックスが表示される。
［代替テキスト］テキストボックスにテキストによる代替を入力する。

事例 3: Microsoft Word を使用して生成した PDF 文書内の画像に /Alt エントリを追加する

この事例は Microsoft Word の場合を示している。同様の機能を実行するソフトウェアツールは他にも存在する。他のソフトウェアツールのリストについては、「アクセシビリティがサポートされている PDF オーサリングツール」を参照のこと。

Word 2000-2003

画像を右クリックし、［図の書式設定］を選択する。
［Web］タブを選択する。
表示されるテキストボックスに代替テキストを入力し、［OK］を押下する。

スクリーンショット：図の書式設定ダイアログの［Web］タブ

Word 2007

画像を右クリックし、［サイズ］を選択する。
［代替テキスト］タブを選択する。
表示されるテキストボックスに代替テキストを入力し、［OK］を押下する。

［サイズ］ダイアログの［代替テキスト］タブ

事例 4: OpenOffice.org Writer 2.2 を使用して生成した PDF 文書内の画像に /Alt エントリを追加する

この事例は Open Office.org Writer の場合を示している。同様の機能を実行するソフトウェアツールは他にも存在する。他のソフトウェアツールのリストについては、「アクセシビリティがサポートされている PDF オーサリングツール」を参照のこと。

画像のコンテキストメニューから［図］を選択する。
［オプション］タブを選択する。
［代替 (テキストのみ)］テキストボックスに代替テキストを入力し、［OK］をクリックする。

スクリーンショット:［図］ダイアログの［オプション］タブ

事例 5: /Alt エントリを使用して PDF 文書内の画像にテキストによる代替を追加する

山と月と木々の画像の場合、/Alt プロパティは次のように使用される (通常、オーサリングツールを使用して行う)。


/Figure <</Alt (Sketch of Mountains with moon rising over trees) >>

この画像は別の名前のタグで表示される場合がある。別の名前が使用されるのは、タグ名が英語以外の言語で記述されているか、特定のツールで何らかの理由で別の名前が使用されているためである。そのような状況では、PDF 文書の StructTreeRoot にある RoleMap に、PDF 文書で使用される標準的な構造タイプを持つ画像で使用されるタグの名前 (この場合は Figure) を明示的に割り当てるエントリが含まれていなければならない。RoleMap に Shape タグと Figure タグのエントリマッピングだけが含まれる場合、ロールマップ情報は次のように表示される。


/RoleMap << /Shape /Figure >>

この場合、/Alt エントリは次のように使用することもできる。


/Shape <</Alt (Crater Lake in the summer, with the blue sky, clouds and crater walls perfectly reflected in the lake) >>

プロパティリストの /Alt エントリは、他のエントリと組み合わせることができる。

参考リソース

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

Section 14.9.4 (Replacement Text) in PDF 1.7 (ISO 32000-1)
Acrobat and Accessibility
PDF Reference 1.6, 10.8.2 Alternate Descriptions
PDF and Accessibility

G94: 非テキストコンテンツに対して、それと同じ目的を果たし、かつ同じ情報を示す、簡潔なテキストによる代替を提供する

検証

手順

次のいずれかの方法で、等価テキストを必要とする画像に /Alt エントリがタグで囲まれていることを確認する:
- PDF 文書をスクリーンリーダーで読み上げ、非テキストオブジェクトにタブ移動するときに代替テキストが読み上げられる (タブ移動が可能な場合)。または、コンテンツが 1 行単位で読み上げられるときにテキストによる代替が読み上げられる。
- PDF エディターを使用して、画像ごとに代替テキストが表示させる。
- /Alt エントリの値を表示できるツール (aDesigner など) を使用して PDF 文書を開き、GUI サマリを表示して、画像のテキストによる代替を読む。
- アクセシビリティ API を通じて文書を表示するツールを使用して、画像が必須のテキスト同等物を持つことを確認する。

期待される結果

代替テキストを必要とする文書内の各画像に対して、1.の結果が真である。

PDF2: PDF 文書内でしおりを作成する

適用 (対象)

タグ付き PDF 文書

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.5 (複数の手段)
- クイックリファレンス 2.4.5 (複数の手段)
- 達成基準 2.4.5 (複数の手段)を理解する

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

PDF2 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法の目的は、利用者が長い文書でしおり (アウトライン辞書のアウトラインエントリ) を使用してコンテンツを見つけられるようにすることである。

認知障害のある利用者は、多数のページを読み進めるよりも、文書の概要を提供する階層的なアウトラインを好む場合がある。また、これは文書内を移動する方法として一般的なものであり、どのような利用者にとっても役立つものである。

事例

事例 1: Microsoft Word 2007 で作成した目次を変換し、Adobe Reader 9 および Acrobat 9 Pro のしおりを作成する

この事例は Microsoft Word と Adobe Acrobat Pro の場合を示している。同様の機能を実行するソフトウェアツールは他にも存在する。他のソフトウェアツールのリストについては、「アクセシビリティがサポートされている PDF オーサリングツール」を参照のこと。

Word 文書の最初に目次を作成する。
名前を付けて保存 > PDF (*.pdf) を選択し、次の両方の項目を有効にして Word 文書を PDF に変換する。
- タグ付き Adobe PDF でアクセシビリティと折り返しを有効にする
- Word の見出しをしおりに変換

変換された文書の目次エントリは、文書内の見出しにリンクされる。

さらに、左側のナビゲーションウィンドウに、見出しが PDF のしおりとして表示される。

スクリーンショット: Word文書の見出しから生成された目次としおりを表示しているPDF文書

文書に用語集やインデックスが含まれている場合、これらのセクションの見出しが目次に (またナビゲーションウィンドウのしおりとして) 表示される。また、目次は、しおりも付けられるようにするために、見出しによってマークアップされなければならない。

このマークアップがオーサリングツールによって行われていない場合は、Adobe Acrobat Pro を使用してタグを設定することができる。変換された見出しを変更する方法または新しい見出しを追加する方法については、PDF9: PDF 文書内のコンテンツを見出しタグでマークアップすることによって見出しを作成するを参照のこと。

この事例には、working example of creating bookmarks with Word 2007 でしおりを作成するサンプル (Word ファイル) がある。

事例 2: OpenOffice.org Writer 2.2 で作成した目次を変換し、Adobe Reader 9 および Acrobat 9 Pro のしおりを作成する

この事例は、OpenOffice.org Writer と Adobe Acrobat Pro および Reader の場合を示している。同様の機能を実行するソフトウェアツールは他にも存在する。他のソフトウェアツールのリストについては、「アクセシビリティがサポートされている PDF オーサリングツール」を参照のこと。

OpenOffice.org Writer 文書の最初に目次を作成する。
- 挿入 > 目次と索引 > 目次と索引 > 目次と索引の挿入
ファイル > PDF としてエクスポートを選択し、Options ダイアログボックスでタグ付き PDF を選択して、文書を PDF に変換する。

スクリーンショット: OpenOffice.org Writerの［目次と索引の挿入］ダイアログ

変換された文書の目次エントリは、文書内の見出しにリンクされ、左側のナビゲーションウィンドウに PDF のしおりとして表示される。OpenOffice.org の目次としおりは、事例 1 と同様に表示される。

この事例には、working example of creating bookmarks with OpenOffice Writer でしおりを生成するサンプル (Open Document Text ファイル) がある。

事例 3: 変換後に Adobe Acrobat 9 Pro を使用して、しおりを追加する

タグ付き PDF に変換した後で、自動的に生成されなかったしおりを追加することができる。変換されたしおりと同様に、タグ付きしおりでも文書内の構造情報が使用される。

しおりパネルでオプションメニューを選択し、［ストラクチャから新規しおり作成］を選択する。
構造エレメントダイアログボックスで、タグ付きしおりとして指定するエレメントを選択する。

次の画像は、しおりオプションメニューを示している。

スクリーンショット:［しおり］のオプションメニュー

次の画像は、しおりを付けるために文書内のリンクを選択するようすを示している。

スクリーンショット:「リンク」を選択して、しおり作成に用いられるタグ付けされた要素

タグ付きしおりは、タイトルのない新規しおりの下にネストされている。新規しおりのコンテキストメニューから「名前を変更」オプションを選択して、次の画像に示すように新規しおりの名前を変更する。

スクリーンショット: 文書中のリンクに対するしおり

この事例には、working example of creating bookmarks with Acrobat Pro で作成したしおりのサンプル (PDF ファイル) がある。

事例 4: アウトライン階層によってしおりを作成する

次のコードフラグメントは、しおりの作成に使用するアウトライン階層の一部を示している。これは通常、オーサリングツールを使用して行う。

121 0 obj
 << /Type /Outlines
    /First 22 0 R
    /Last 29 0 R
    /Count 6
 >>
endobj
22 0 obj
 << /Title (Applying Guerrilla Tactics to Usability Testing by People with Disabilities)
    /Parent 21 0 R
    /Next 29 0 R
    /First 25 0 R
    /Last 28 0 R
    /Count 4
    /Dest [3 0 R /XYZ 0 792 0]
 >>
endobj
25 0 obj
 << /Title (Getting started)
    /Parent 22 0 R
    /Next 26 0 R
    /Dest [3 0 R /XYZ null 701 null]
 >>
endobj

参考リソース

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

Section 12.3.3 (Document Outline) in PDF 1.7 (ISO 32000-1)
PDF and Accessibility

G64: 目次を提供する

検証

手順

しおりパネルにしおりが表示されていることを確認する。
しおりが文書内の正しいセクションにリンクされていることを確認する。

期待される結果

1. 及び 2. の結果が真である。

PDF3: PDF 文書で正しいタブ順序と読み上げ順序を確保する

適用 (対象)

タグ付き PDF 文書

これは、次の達成基準に関連する達成方法である:

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

PDF3 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法の目的は、コンテンツの意味と一貫性がある論理的な順序で利用者がコンテンツ内を移動できるようにすることである。正しいタブ順序と読み上げ順序は通常、PDF のオーサリングツールを使用して指定できる。

画面を見ている利用者にとっては、PDF コンテンツの論理的な順序は画面上の視覚的な順序でもある。キーボードおよび支援技術の利用者の場合は、インタラクティブなエレメント (フォームフィールドおよびリンク) を含むコンテンツ内のタブの順序によって、利用者がコンテンツ内を移動できる順序が決定される。タブの順序には、文書の論理的な順序が反映されていなければならない。

論理構造は、文書がタグ付き PDF として保存されたときに作成される。PDF 文書の読み上げ順序は、インタラクティブなエレメントを含めて、文書エレメントのタグ順序によって主に決定されるが、個々のタグの中のコンテンツの順序は PDF 文書のコンテンツのツリー構造によって決定される。

読み上げ順序が正しくないと、キーボードおよび支援技術の利用者がコンテンツを理解できない場合がある。例えば、複数の列がある文書では、視力のある利用者にとっては読む順序は視覚的に明確であり、最初の列の上から下へ、続いて次の列の先頭に移動するというようになる。しかし文書のタグ付けが適切でないと、スクリーンリーダーは文書の二つの列を一つの列として解釈して、列をまたいで上から下へ読み上げる場合がある。

正しい読み上げ順序を指定する最も簡単な方法は、タグ付き PDF に変換する前に、文書の作成に使用するオーサリングツールで文書を正しく構成することである。ただし、グラフィック、表、脚注、サイドバー、フォームフィールドなどのエレメントが含まれた複雑なレイアウトのページは、正しい読み上げ順序でタグ付き PDF に変換されない可能性がある。このような不整合は、Acrobat Pro などの修復ツールで修正する必要がある。

フォームフィールドが含まれる PDF 文書に正しい読み上げ順序が設定された場合には、すべてのフォームフィールドが適切なタブ順序で配置され、また PDF 内の他のコンテンツとの相対的な順序も正しく設定される。一般的なタブ順序エラーには次のものがある。

タグ付きコンテンツにフォームフィールドが含まれていない。
フォームフィールドが、非インタラクティブなコンテンツの末尾など、PDF コンテンツ内の誤った場所にある。

事例

事例 1: Microsoft Word 2007 を使用して 2 段組みの文書を作成する

Word のページレイアウト > 段組みツールを使用して作成した複数列の文書は通常、タグ付き PDF に変換したときに正しい読み上げ順序になる。次の画像は Word の段組みツールを示している。

スクリーンショット: Wordの段組みツールで、ページを二段組みにするために「2段」が選択されている。

この事例のサンプルとして、Word 2007 を使用した 2 段組み文書のサンプル (Word ファイル) と Word 2007 を使用した 2 段組み文書のサンプル (PDF ファイル)がある。

事例 2: OpenOffice.org Writer 2.2 を使用して 2 段組みの文書を作成する

この事例は OpenOffice.org Writer の場合を示している。同様の機能を実行するソフトウェアツールは他にも存在する。他のソフトウェアツールのリストについては、「アクセシビリティがサポートされている PDF オーサリングツール」を参照のこと。

OpenOffice.org Writer の書式 > 段組みツールを使用して作成した複数列の文書は通常、タグ付き PDF に変換したときに正しい読み上げ順序になる。次の画像は OpenOffice.org Writer の段組みツールを示している。

スクリーンショット: OpenOffice.org Writerの段組みツールで、ページを二段組みにするために「2段」が選択されている。

この事例のサンプルとして、OpenOffice Writer を使用した 2 段組み文書のサンプル (OpenOffice ファイル) と OpenOffice Writer を使用した 2 段組み文書のサンプル (PDF ファイル)がある。

事例 3: Adobe Acrobat 9 Pro を使用して一つまたは複数のページのタブ順序を設定する

タグ付き PDF 文書で次の手順を実行する。

次のいずれかの方法で［ページ］パネルを開く。
- ページアイコンをクリック
- 表示 > ナビゲーションパネル > ページを選択
一つまたは複数のページサムネイルを選択する。
選択したサムネイルのコンテキストメニューから［ページのプロパティ］を選択する。
［ページのプロパティ］ダイアログボックスの［タブの順序］タブを選択する。
必要に応じて、タブの順序オプションを選択する。

オプション	説明
行の順序を使用	左上のフィールドからタブ移動を開始して、まず左から右に移動し、次に表の行を 1 行ずつ下に移動する。
列の順序を使用	左上のフィールドからタブ移動を開始して、まず上から下に移動し、次に表の列を左から右に 1 列ずつ移動する。
文書構造を使用	タグ付き文書では、オーサリングアプリケーションで指定されたタグ順序で移動する。注記: 通常はこれが正しい読み上げ順序であり、タグ付き文書に対してデフォルトで選択される。
指定しない	Acrobat Pro の旧バージョンで作成された文書の場合は、タブ順序はデフォルトでは「指定しない」となる。この設定では、最初にフォームフィールドを順にタブ移動し、次にリンク、コメントが行の順にタブ移動する。これは正しい読み上げ順序ではないかもしれない。

スクリーンショット: Adobe Acrobat Professionalの［ページのプロパティ］ダイアログ。選択肢として、行の順序を使用、列の順序を使用、文書構造を使用、指定しないの四つがあり、「文書構造を使用する」が選択されている。これがデフォルトである。

この事例のサンプルとして、タブ順序設定のサンプル (Word ファイル) とタブ順序設定のサンプル (PDF ファイル)がある。

事例 4: Adobe Acrobat 9 Pro のタグパネルを使用して読み上げ順序を修正する

事例 5 の読み上げ順序を修正するには、［タグ］パネルで次のいずれかの操作を行う。

H1 タグを必須フィールドのテキスト (H2 タグ) の前にドラッグ＆ドロップ
H2 タグを切り取り、H1 タグの後に貼り付け

次の画像では、テキストと見出しの読み上げ順序が正しくなっている。つまり、コンテンツのエレメント H1 と H2 が、正しい読み上げ順序に従って入れ替えられたことになる。

スクリーンショット：Adobe Acrobat Proで修正された読み上げ順序。H1タグとH2タグが入れ替えられて、正しい順序になっている。

参考リソース

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

Section 14.8 (Tagged PDF) in PDF 1.7 (ISO 32000-1)
PDF and Accessibility
Making PDF documents accessible with Adobe Acrobat Pro

検証

手順

次のいずれかの方法で、コンテンツが正しい読み上げ順序になっていることを確認する。
- スクリーンリーダーまたは読み上げ機能があるツールを使用して PDF 文書を読み上げ、各エレメントが正しい順序で読み上げられていることを確認する
- アクセシビリティ API を通じて文書を表示するツールを使用して、読み上げ順序が正しいことを確認する
次のいずれかの方法で、フォーカス可能なコンテンツのタブ順序が正しいことを確認する。
- Tab キーを使用して、文書内のフォーカス順序をトラバースする。
- タブ順序設定を指定するページオブジェクトのエントリを表示できるツールを使用して、PDF 文書を開き、設定を表示する。

期待される結果

1. 及び 2. の結果が真である。

PDF4: PDF 文書の Artifact タグによって装飾的な画像を隠す

適用 (対象)

タグ付き PDF 文書

これは、次の達成基準に関連する達成方法である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

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

PDF4 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法の目的は、/Artifact タグを使用して、支援技術で無視できるように PDF 文書内の純粋に装飾的な画像をマークする方法を示すことである。これは通常、PDF のオーサリングツールを使用して行う。

PDF では、一般的にアーティファクトとは、作成されたコンテンツに含まれないグラフィックオブジェクトまたはその他のマーキングを意味する。アーティファクトの例としては、ページのヘッダーまたはフッター情報、ページのセクションを分ける線またはその他のグラフィック、装飾的な画像などがある。

事例

事例 1: Adobe Acrobat 9 Pro の TouchUp 読み上げ順序ツールを使用して、背景画像をアーティファクトとしてマークする

TouchUp 読み上げ順序ツールを使用して、画像を「背景」としてマークすることができる。これにより画像は文書のタグ構造から削除される。

Acrobat Pro でアドバンスト > アクセシビリティ > TouchUp 読み上げ順序を選択し、TouchUp 読み上げ順序ツールを開く。
文書内の装飾的な画像を選択する。
TouchUp 読み上げ順序ツールで、［背景］ボタンをクリックし、選択した画像をタグ構造から削除する。

下のスクリーンショットはこの事例を示している。

スクリーンショット: TouchUp 読み上げ順序ツールを使用して、タグツリーから画像を削除

この事例のサンプルとして、装飾的な画像作成のサンプル (Word ファイル) と装飾的な画像作成のサンプル (PDF ファイル)がある。

事例 2: /Artifact タグまたはプロパティリストを使用して、画像を PDF 文書内のアーティファクトとしてマークする

PDF 仕様を使用すると、PDF 1.7 (ISO 32000-1)の節 14.8.2.2 (Real Content and Artifacts) に定義されているように、画像を「アーティファクト」としてマークすることができる。アーティファクトは、/Artifact タグと共に、マークされたコンテンツ順序に含められることで実際のコンテンツと明示的に区別される。

/Artifact

BMC  ...  EMC

または

/Artifact propertyList

BDC  ...  EMC

前者は一般的なアーティファクトを特定するために使用され、後者はプロパティリストが関連付けられているアーティファクトで使用される。テキストのリフローを可能にするために、アーティファクトは可能な限りプロパティリストを関連付けて定義すべきである。境界ボックスが指定されていないアーティファクトは、リフロー中に削除される可能性がある。

アーティファクトのプロパティリストのエントリには、Type、BBox、Attached、Subtype などがある。

参考リソース

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

Section 14.8.2.2 (Real Content and Artifacts) in PDF 1.7 (ISO 32000-1)
PDF and Accessibility

検証

手順

純粋に装飾的な画像について、次のいずれかの方法を使用して確認すると、アーティファクトとしてマークされている。
- PDF 文書をスクリーンリーダーで読み上げた際に、コンテンツが 1 行単位で読み上げられるときに装飾的な画像が読み上げられない。
- PDF エディターを使用して、装飾的な画像がアーティファクトとしてマークされていることを確認する。
- 文書を折り返し表示にすると、装飾的な画像がページに表示されない。
- /Artifact エントリまたはプロパティリストを表示できるツール (aDesigner など) を使用して PDF 文書を開き、装飾的な画像がアーティファクトとしてマークされていることを確認する。
- アクセシビリティ API を通じて文書を表示するツールを使用して、装飾的な画像が API を通じて表示されていないことを確認する。

期待される結果

1. の結果が真である。

PDF5: PDF フォームで必須項目のフォームコントロールを示す

適用 (対象)

フォームを持つタグ付き PDF 文書

これは、次の達成基準に関連する達成方法である:

達成基準 3.3.1 (エラーの特定)
- クイックリファレンス 3.3.1 (エラーの特定)
- 達成基準 3.3.1 (エラーの特定)を理解する
達成基準 3.3.2 (ラベル又は説明)
- クイックリファレンス 3.3.2 (ラベル又は説明)
- 達成基準 3.3.2 (ラベル又は説明)を理解する
注記: この達成方法は、達成基準 3.3.2 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 3.3.2 を理解するを参照すること。
達成基準 3.3.3 (エラー修正の提案)
- クイックリファレンス 3.3.3 (エラー修正の提案)
- 達成基準 3.3.3 (エラー修正の提案)を理解する

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

PDF5 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法は、PDF フォームで入力する必要のあるフィールドが入力されていないことを利用者に通知することを目的としている。必須フィールドは、フォームフィールドの辞書の /Ff エントリを使用して実装する PDF 1.7 (ISO 32000-1) の節 12.7 (Interactive Forms) の Table 220 を参照のこと。これは通常、PDF のオーサリングツールを使用して行う。

エラーが見つかった場合、テキストに含まれているエラーの性質について説明するアラートダイアログボックスが表示される。これは作成者が作成したスクリプトを通じて指定できる (例えば、SCR18: クライアントサイドのバリデーション及びアラートを提供するを参照のこと)。Adobe Acrobat Pro や LiveCycle などのユーザエージェントでは、(以下の事例で説明されているように) 自動的にアラートを表示できる。

注記: 利用者がアラートダイアログボックスを閉じた後に、エラーの発生したフィールドにキーボードのフォーカスが移動するようにスクリプトを記述すると役立つ。ただし利用者によっては、アラートが表示される直前にフォーカスされていたコントロールにフォーカスが残ることを想定する場合がある。作成者は、利用者が想定するとおりにフォーカスを移動するよう注意を払う必要がある。例えば、必須の電話番号が入力されていないことを示すアラートが表示された場合に、アラートを閉じると電話番号フィールドにフォーカスが置かれるようにすることは、利用者にとって役立ち、想定される動作であると考えられる。ただし場合によっては、これが不可能なことがある。ページ上で複数の入力エラーが発生した場合には、エラーを通知するために別のアプローチをとる必要がある (例えば、Adobe: JavaScript for Acrobat を参照のこと)。

利用者が必ずエラーが発生したことに気付き、何が間違っているのかを判断し、修正できるようにすることは、ソフトウェアのユーザビリティとアクセシビリティにとって重要である。この目的を達成することは、すべての利用者が簡単かつ確実にトランザクションを完了できるようにするのに役立つ。

必須フォームコントロールのラベル

エラーが発生する可能性があることを利用者が認識することも重要である。この情報は、「日付 (必須)」のようなラベルや、赤いアスタリスクによって必須フィールドを示すなどの方法で組み込むことができる (必須フィールドがある各フォームに説明文が必ず表示されるようにする (例: "* = 必須フィールド"))。PDF10: PDF 文書内のインタラクティブなフォームコントロールにラベルを付けるを参照のこと。

事例

事例 1: Adobe Acrobat 9 Pro を使用して PDF フォーム内に必須フィールドを作成する

この事例は Adobe Acrobat Pro の場合を示している。同様の機能を実行するソフトウェアツールは他にも存在する。他のソフトウェアツールのリストについては、アクセシビリティがサポートされている PDF オーサリングツールを参照のこと。

フィールドのコンテキストメニューから［プロパティ］ダイアログボックスを選択する。
フィールドが必須である場合は、［必須］チェックボックスを選択する。このチェックボックスによって、選択されたフォームフィールドへの入力が利用者に強制される。必須フィールドが空白のまま利用者がフォームを送信しようとすると、エラーメッセージが表示され、空白の必須フォームフィールドが強調表示される。

スクリーンショット:［テキストフィールドのプロパティ］ダイアログで、「必須」のチェックボックスが選択されている。

この事例のサンプルとして、Acrobat で必須フィールドを作成したサンプル (PDF ファイル) がある。

事例 2: Adobe LiveCycle Designer ES 8.2.1 を使用して PDF フォーム内に必須フィールドを作成する

この事例は Adobe LiveCycle Designer の場合を示している。同様の機能を実行するソフトウェアツールは他にも存在する。他のソフトウェアツールのリストについては、アクセシビリティがサポートされている PDF オーサリングツールを参照のこと。

フォームコントロールのコンテキストメニューから、パレット > オブジェクトを選択する。
［種類］プルダウンメニューから［利用者定義 - 必須］を選択する。
［空白のメッセージ］フィールドにエラーメッセージを入力する。このメッセージは、利用者が必須フィールドに値を入力せずにフォームを送信しようとした場合に表示される。

必須フィールドが空白のまま利用者がフォームを送信しようとすると、［空白のメッセージ］に入力されたテキストが表示され、空白の必須フォームフィールドが強調表示される。

次の画像は、「必須」を選択した Adobe LiveCycle のオブジェクトパレットを示している。

スクリーンショット:［利用者定義 - 必須］を選択したAdobe LiveCycle Object のパレット"

フォームラベルに明示的なテキストを追加して (「(必須)」など)、必須フィールドを示すこともできる。

この事例のサンプルとして、LiveCycle Designer で必須フィールドを作成したサンプル (PDF ファイル) がある。

事例 3: /Tx フィールドタイプおよび Ff フラグを使用して、PDF フォームに必須テキストフィールドを追加する

次のコードフラグメントは、一般的なテキストフィールドのオブジェクト定義で一般的に使用されるコードを示している。テキストフィールドは必須であり、Ff フラグを使用している。これは通常、オーサリングツールを使用して行う。


<< /AP -dict-                                                   
   /DA /Helv  0 Tf 0 g
   /DR -dict-
   /F 0x4
   /FT Tx              % FT key set to Tx for Text Field
   /Ff 0x2             % Ff integer 0x2 value indicates required
   /P -dict-
   /Rect -array-
   /StructParent 0x1
   /Subtype Widget
   /T First            % Partial field name First
   /TU First name (required)  % TU tool tip value serves as short description
   /Type Annot
   /V Pat Jones
>>
...
<Start Stream>
 BT
  /P <</MCID 0 >>BDC
  /CS0 cs 0  scn 
  /TT0 1 Tf
    -0.001 Tc 0.003 Tw 11.04 0 0 11.04 72 709.56 Tm
    [(P)-6(le)-3(as)10(e)-3( )11(P)-6(rin)2(t)-3( Y)8(o)-7(u)2(r N)4(a)11(m)-6(e)]TJ
  0 Tc 0 Tw 9.533 0 Td
  ( )Tj
  -0.004 Tc 0.004 Tw 0.217 0 Td
  [(\()-5(R)-4(e)5(q)-1(u)-1(i)-3(r)-3(e)-6(d)-1(\))]TJ
 EMC
  /P <</MCID 1 >>BDC
  0 Tc 0 Tw 4.283 0 Td
  [( )-2( )]TJ
   EMC
   /ArtifactSpan <</MCID 2 >>BDC
   0.002 Tc -0.002 Tw 0.456 0 Td
  [(__)11(___)11(___)11(___)11(___)11(_)11(____)11(___)11(___)11(__)]TJ
  0 Tc 0 Tw 13.391 0 Td
  ( )Tj
  EMC
 ET
<End Stream>

参考リソース

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

Section 12.7 (Interactive Forms) in PDF 1.7 (ISO 32000-1)
Adobe XML Forms Architecture (XFA)
PDF and Accessibility

検証

手順

それぞれの必須のフォームフィールドについて、次の方法によって、必要な情報や説明文が提供されていることを確認する。

フォームコントロールのラベルに必須であることが示されていることを確認する。
フィールドを空白のままにしてフォームを送信すると、エラーについて説明するアラートが表示されることを確認する。
アクセシビリティ API を通じて文書を表示するツールを使用して、必須プロパティが示されていることを確認する。

期待される結果

1.、2. 及び 3. の結果が真である。

PDF6: PDF 文書でテーブルのマークアップにテーブル要素を使用する

適用 (対象)

テーブルのあるタグ付き PDF 文書

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

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

PDF6 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法の目的は、支援技術で認識されるように PDF 文書内のテーブルをマークアップする方法を示すことである。これは通常、PDF のオーサリングツールを使用して行う。

表の情報は、利用者がテーブルを見られない場合や提示形式が変更された場合でも、情報内の関係を維持する方法で表示されなければならない。情報は、テキスト、数字、画像または他のデータ間の論理的な関係が 2 次元 (垂直と水平) で存在する場合に表と見なされる。これらの関係は、列と行で表わされ、論理的な関係を把握するために列と行が認識可能である必要がある。

タグ付きのテーブルは、Adobe Acrobat で「文書にタグを追加」機能を使用するか、Adobe LiveCycle のオブジェクトライブラリを使用するか、Microsoft Word などのサードパーティアプリケーションから表を PDF に変換することで作成できる。ただし、結果のテーブルは正しくタグが設定されない場合があるので、テーブルのタグ付けの問題が解決されたことを確認する必要がある。

PDF 文書内のテーブルでは、次のような table エレメントの構造タイプが使用される。

テーブルエレメント (Table)
Table エレメントの直接の子としてテーブルのセルの各行を定義する一つまたは複数のテーブル行エレメント (TR)
テーブル行エレメントの直接の子としての一つまたは複数のテーブルヘッダーエレメント (TH) またはテーブルデータエレメント (TD)
二つ以上の行または列にまたがるセルは、RowSpan または ColSpan 属性を使用する必要がある
空白のセルを含むテーブルの場合は、空白の TD セルを追加して各行または列のセルの数が同じになるようにする必要がある

事例

事例 1: Microsoft Word 2007 で PDF 変換時に正しいタグ付き見出しがある表を作成する

表のヘッダー行のコンテキストメニューから［表のプロパティ］を選択する
［行］タブを選択する
次の画像に示すように、「各ページにタイトル行を表示する」を選択する

スクリーンショット：Wordの表の1行目に対して、［表のプロパティ］ダイアログの［行］タブを開き、「各ページにタイトル行を表示する」をチェックして、1行目が見出しセルとしてマークアップされるようにしている。

この事例のサンプルとして、Word 2007 でのタグ付きテーブル見出しのサンプル (Word ファイル)がある。

注記: Microsoft Word では、セルは行見出しではなく列見出しとしてのみマークアップできる。すべての表の列について、見出しとしてマークできるのは最初の行だけである。表に行見出しまたはさらに複雑な見出し構造がある場合、このマークアップは Acrobat Pro などの PDF エディターで追加する必要がある。

事例 2: OpenOffice.org Writer 2.2 で PDF 変換時に正しいタグ付き見出しがある表を作成する

この事例は OpenOffice.org Writer の場合を示している。同様の機能を実行するソフトウェアツールは他にも存在する。他のソフトウェアツールのリストについては、「アクセシビリティがサポートされている PDF オーサリングツール」を参照のこと。

表のコンテキストメニューから［表］を選択する
［体裁］タブを選択する。/p>
次の画像に示すように、「見出しの繰り返し」を選択し、「最初の n 行」リストボックスで「1」を選択する。

スクリーンショット: OpenOffice.org Writerの［表］ダイアログで、［体裁］タブを選択して、「見出しの繰り返し」をチェックして、「最初の n 行」リストボックスで「1」を選択し、1行目が見出しセルとしてマークアップされるようにしている。

この事例のサンプルとして、OpenOffice Writer でのタグ付きテーブル見出しのサンプル (OpenDocument テキストファイル) がある。

注記: OpenOffice.org Writer では、セルは行見出しではなく列見出しとしてのみマークアップできる。すべての表の列について、見出しとしてマークできるのは最初の行だけである。表に行見出しまたはさらに複雑な見出し構造がある場合、このマークアップは Acrobat Pro などの PDF エディターで追加する必要がある。

事例 3: Adobe Acrobat 9 Pro の［タグ］タブを使用してテーブルタグを変更する

変換された文書内のテーブルが正しくタグ付けされていることを確認するには、次の操作を行う。

［表示］メニューからナビゲーションパネル > タブを選択する。

TAdobe Acrobat Pro のテーブルで、［タグ］タブを開くと、全てのテーブルセルがTDでマークアップされている。

この場合、テーブルヘッダーには事例 1 および 2 に示すような書式は設定されておらず、データセルとしてマークされている (TD)。これらを TH タグに変更するには、次の操作を行う。

上の画像に示すように、［タグ］タブで、ヘッダーセルを含むテーブル行を開く
最初のデータセルを選択し、［プロパティ］を選択する
［プロパティ］ダイアログボックスの［タグ］タブで、種類ドロップダウンリストを使用して、「テーブルデータセル」を「テーブルヘッダーセル」に変更する。
テーブルの最初の行にあるすべてのテーブルヘッダーセルについて、同じ操作を繰り返す

スクリーンショット：Adobe Acrobat Pro の表で［タグのプロパティ］ダイアログを使用して、データセルを見出しセルに変更する。

この事例のサンプルとして、Acrobat でのタグ付きテーブル見出しのサンプル (PDF ファイル) がある。

事例 4: テーブルの構造エレメントを使用してテーブルをマークアップする

次のコードフラグメントは、事例 1 ～ 3 に示すような単純なテーブル (ヘッダー行とデータ行) で一般的に使用されるコードを示している。

95 0 obj                %Structure element for a table
 << 
  /A 39 0 R
  /K[96 0 R 101 0 R 106 0 R 111 0 R]
  /P 93 0 R
  /S/Table              %standard structure type is table
 >> 
 endobj
96 0 obj                %Structure element for a table row
 << 
  /K[97 0 R 98 0 R 99 0 R 100 0 R]
  /P 95 0 R
  /S/TR                 %standard structure type is table row
 >> 
 endobj
97 0 obj                %Structure element for a table header
 <</A[23 0 R 120 0 R]
   /K 1
   /P 96 0 R
   /S/TH                 %standard structure type is table head
   /Pg 8 0 R
 >> 
endobj
104 0 obj                %Structure element for table data (cell contents)
 << 
  /A 29 0 R
  /K 7
  /P 101 0 R
  /S/TD                  %standard structure type is table data
  /Pg 8 0 R
 >> 
endobj

参考リソース

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

Section 14.8.4.3.4 (Table Elements) in PDF 1.7 (ISO 32000-1)
PDF and Accessibility

検証

手順

各テーブルで、次のいずれかを確認する。
- PDF 文書をスクリーンリーダーで読み上げると、テーブルヘッダーおよびデータセル間の論理的関係を維持する方法で表の情報が読み上げられる。
- PDF エディターを使用し、適切な TR、TH および TD タグが正しい読み上げ順序でテーブルツリー内の階層に配置されていることを確認する。
- テーブルエレメントを表示できるツールを使用して PDF 文書を開き、テーブル構造を表示して、適切な TR、TH および TD 構造が含まれていることを確認する。
- アクセシビリティ API を通じて文書を表示するツールを使用して、テーブル構造に適切な TR、TH および TD 構造が含まれ、正しい読み上げ順序と階層になっていることを確認する。

期待される結果

1. の結果が真である。

PDF7: スキャンされた PDF 文書で OCR を実行し、実際のテキストを提供する

適用 (対象)

スキャンされた PDF 文書

これは、次の達成基準に関連する達成方法である:

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

PDF7 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法の目的は、視覚的にレンダリングされたテキストが、視覚的提示によって読みやすさが損なわれることなく、知覚可能な方法で提示されることを保証することである。

テキストをスキャンした画像で構成される文書は、文書のコンテンツが画像であって検索可能なテキストではないので、本質的にアクセシブルではない。支援技術で語句を読み上げたり抽出したりすることはできない。利用者はテキストを選択、編集、サイズ変更またはリフローすることも、テキストや背景色を変更することもできない。作成者は PDF を操作してアクセシビリティを実現することができない。

これらの理由から、作成者はテキストの画像ではなく実際のテキストを使用し、Microsoft Word や Oracle Open Office などのオーサリングツールを使用してコンテンツを作成し PDF に変換すべきである。

作成者がソースファイルやオーサリングツールを利用できない場合は、光学式文字認識 (OCR) を使用することで、テキストをスキャンした画像を PDF に変換できる。その後で、Adobe Acrobat Pro を使用することでアクセシブルなテキストを作成できる。

事例

事例 1: Adobe Acrobat 9 Pro を使用して、テキストの画像ではなく実際のテキストを生成する

この事例では、テキストをスキャンした、単純な 1 ページの画像を使用している。文書に実際のテキストが確実に格納されるようにするには、以下の手順を実行する。

可能な限り高い解像度で文書をスキャンして、OCR のパフォーマンスを向上させる
スキャンされた文書を Acrobat Acrobat Pro に読み込む。文書構造を使用 > OCR テキスト認識 > OCR を使用して［テキストを認識］を選択する
次のダイアログボックスで、「ページ」(1 ページのみ変換する場合は「現在のページ」) の下の「すべてのページ」ラジオボタンを選択し、［OK］を選択する
「設定」リストで「編集」を選択する。次のダイアログボックスで、「PDF の出力形式」ドロップダウンリストの「テキストとグラフィック」を選択する。これはアクセシビリティを確保するために重要である
解像度とテキストの明瞭度に応じて、OCR が単語や文字のイメージを実際のテキストに変換する。Acrobat Pro で認識されないテキストは、「不明テキスト」と表示される。これは、正しく認識されなかったことが疑われるテキストエレメントである
不明テキストを修正するには、文書構造を使用／OCR テキスト認識／最初の不明テキストを表示を選択する。Acrobat Pro では不明テキストが一つずつ表示され、不明テキストは Acrobat Pro TouchUp ツールを使用して修正できる
アドバンスト > アクセシビリティ > 文書にタグを追加を実行する
アドバンスト > アクセシビリティ > フルチェックを実行して、アクセシビリティをテストする

注記: 別の方法として、文書構造を使用 > OCR テキスト認識 > すべての不明テキストを表示を使用し、すべての不明テキストを同時に表示して編集を素早く行うこともできる。

次の画像は、Adobe Acrobat Pro に表示されている、スキャンされた 1 ページの文書を示している。

Acrobat Pro で表示されているスープのレシピをスキャンしたページ

次の画像は、文書にタグを追加した後で変換されたコンテンツを示している。コンテンツに正しくタグ付けし、最終的に意図した文書を得るには、TouchUp 読み上げ順序ツールとタグパネルを使用する必要があると考えられる。この事例では、らせん綴じの本の画像がタグ付けされ変換されている。TouchUp 読み上げ順序ツールを使用することで、画像が (装飾的な) 背景画像として非表示になっている (「PDF4：PDF 文書の Artifact タグによって装飾的な画像をタグ構造から削除する」を参照のこと)。レシピのタイトルは、第 1 レベルのヘッダーとしてタグ付けされている。

A tagged converted page in Acrobat Pro でタグ付きに変換されたスープのレシピのページ。各スープの名前が第1レベルの見出しで、らせん綴じの本の画像は装飾的な画像としてタグ構造から削除されている。

注記： Acrobat Pro では、ファイルに対して OCR を実行すると自動的にタグが追加される場合がある。

この事例のサンプルとして、実際のテキストを生成するサンプル (PDF ファイル) と OCR の実行結果サンプル (PDF ファイル) がある。

参考リソース

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

PDF and Accessibility

G140: 異なる提示を可能にするために、情報と構造を表現から分離する

検証

手順

OCR を使用して各ページをテキストに変換した場合には、次のいずれかの方法を使用して、PDF が正しく変換されたことを確認する。
- スクリーンリーダーまたは読み上げ機能があるツールを使用して PDF 文書を読み上げると、すべてのテキストが正しい順序で読み上げられている。
- 文書をテキストとして保存すると、変換されたテキストが完全であり、正しい読み上げ順序になっている。
- 変換されたコンテンツを表示できるツールを使用して PDF 文書を開くと、すべてのテキストが変換されて正しい読み上げ順序になっている。
- アクセシビリティ API を通じて文書を表示するツールを使用して、すべてのテキストが変換されて正しい読み上げ順序になっていることを確認する。

期待される結果

1. の結果が真である。

PDF8: 構造要素の E エントリによって略語の定義を提供する

適用 (対象)

略語または頭字語を含んでいるタグ付き PDF 文書

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.4 (略語)
- クイックリファレンス 3.1.4 (略語)
- 達成基準 3.1.4 (略語)を理解する

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

PDF8 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法の目的は、最初に出現した略語に対して略語の拡張または定義を提供することである。例えば、「WCAG」という略語の場合は、文書内で最初に出現したときに「Web Content Accessibility Guidelines (WCAG)」のように表記される必要がある。

これを行うには、通常は PDF のオーサリングツールを使用して、構造エレメントに対して /E エントリを使用して拡張テキストを設定する。Span 構造エレメントは通常、略語のタグ付けに使用されるが、/E エントリはすべての構造エレメントで有効である。

この達成方法は、頭字語や頭文字語を含む、すべての略語に適用できる。この方法では、略語が最初に出現したときに、略語と拡張テキストの両方を表示させる必要がある。それによって、後で略語を使用したときに容易に認識できるようになる。

PDF 文書は、略語に対する拡張テキストを提供することで強化される。実際に、単語の判読が困難な利用者、画面拡大表示 (コンテキストが不明瞭になる) が必要な利用者、記憶に障害がある利用者、またはコンテンツによる理解が困難な利用者が確実に理解できるようにするには、このようなアクセシビリティのための拡張が必要になる。

事例

事例 1: Adobe Acrobat 9 Pro のタグパネルを使用して、略語に /E エントリを追加する

タグ付き PDF 文書で次の手順を実行する。

表示 > ナビゲーションパネル > タグを使用して［タグ］パネルを選択する
最初に出現する、拡張が必要な略語化されたテキストを選択する。選択したテキストが大きなタグの一部である場合には、［タグ］パネルのオプションメニューの「選択範囲からタグを作成」を選択し、新しい Span タグを作成する。この事例では、(LBody タグ内の)「WCAG2」というテキストが Span タグで囲まれている。
［タグ］パネルで、拡張されたテキストのコンテキストメニューから「プロパティ」を選択し、Span タグの［TouchUp のプロパティ］ダイアログボックスを開く。
［TouchUp のプロパティ］ダイアログボックスの［コンテンツ］タブに拡張テキストを入力し、最初に選択したテキストを入力する。

次の画像はこの達成方法を示している。

スクリーンショット:［タグ］パネルを使用して、略語に拡張テキストを追加。「WCAG2.0」というテキストを選択して、それに対する Span タグを作成し、［TouchUp のプロパティ］ダイアログボックスで「WCAG2.0」の拡張として、拡張テキスト「Web Content Accessibility Guidelines (WCAG) 2.0」を入力する。

この事例のサンプルとして、略語の定義を提供するサンプル (Word ファイル)、略語の定義を提供するサンプル (OpenDocument テキストファイル) と略語の定義を提供するサンプル (PDF ファイル)がある。

事例 2: /E エントリを含む /Span 構造エレメントを使用して略語を定義する

次のコードフラグメントは、/Span 構造エレメントを使用して略語を定義する一般的なコードを示している。

この事例では、「Sugar is commonly sold in 5 lb bags.」という文を使用している。略語「lb」は、/E エントリによって /Span 構造エレメントとしてタグ付けされている (通常、オーサリングツールを使用して行う)。


1 0 obj                                  % 構造エレメント
   << /Type /StructElemen
            /S /Span                      % エレメントの型
            /P ...                        % 構造階層の親
            /K << /Type /MCR
                        /Page 2 0 R       % マーク付きコンテンツのシーケンスを含むページ
                        /MCID 0           % "lb" のマーク付きコンテンツの識別子
               >>
            /E  (pound, lb)
    >>
 endobj

事例 3: /E エントリを含む /TH 構造エレメントを使用して略語を定義する

解説に記載されているように、/E エントリはすべての構造エレメントで有効である。

次のコードフラグメントは、/E エントリを使用して略語を定義する一般的なコードを示している。

各月の列を含むテーブルでは、列ヘッダーの値として略語が使用される。各略語を拡張したものが、/TH 構造エレメントの /E エントリとして提供される (通常、オーサリングツールを使用して行う)。


1 0 obj                                  % 構造エレメント
   << /Type /StructElemen
            /S /TH                        % エレメントの型
            /P ...                        % 構造階層の親
            /K << /Type /MCR
                        /Page 2 0 R       % マーク付きコンテンツのシーケンスを含むページ
                        /MCID 0           % "Dec" のマーク付きコンテンツの識別子
               >>
            /E  (December, Dec)
    >>
 endobj

参考リソース

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

Section 14.9.5 (Expansion of Abbreviations and Acronyms) in PDF 1.7 (ISO 32000-1)
Microsoft Inspect.exe tool
PDF and Accessibility

検証

手順

次のいずれかの方法で、最初に出現した、拡張が必要な略語に /E エントリがタグによって指定されていること、また略語と拡張テキストの両方が入力されていることを確認する。
- Windows では、Microsoft の Inspect.exe ツール、または MSAA インタフェースの検査が可能なその他のツールを使用して、文書ツリー内の略語のテキストを特定し、略語の値が拡張テキスト内にあることを確認する。
- PDF エディターでは、略語であるテキストのタグを特定し、対応するタグのプロパティの「拡張テキスト」フィールドにより、各略語に拡張や定義が提供されていることを確認する。
- PDF 文書をスクリーンリーダーで読み上げると、コンテンツが 1 行単位で読み上げられるときに、最初に出現した略語および拡張テキストが読み上げられる。
- /E エントリの値を表示できるツール (aDesigner など) を使用して PDF 文書を開き、GUI サマリを表示して、略語の拡張テキストを読んで確認する。
- アクセシビリティ API を通じて文書を表示するツールを使用して、略語の拡張テキストが正しく実装されていることを確認する。

期待される結果

1. の結果が真である。

PDF9: PDF 文書内のコンテンツを見出しタグでマークアップすることによって見出しを作成する

適用 (対象)

見出しのあるタグ付き PDF 文書

これは、次の達成基準に関連する達成方法である:

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

PDF9 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この実装方法の目的は、支援技術で認識されるように PDF 文書内の見出しをマークアップする方法を示すことである。見出しは構造ツリーの中で見出しエレメント (H, H1, H2, ... H6) を用いてマークアップされる。これは通常、PDF のオーサリングツールを使用して行う。

見出しマークアップは次の目的のために使用できる。

メインコンテンツの開始を示す
メインコンテンツ領域内のセクション見出しをマークアップする
トップまたはメインナビゲーション、左側または第 2 のナビゲーション、フッターナビゲーションなど、様々なナビゲーションセクションを区別する
視覚的な見出しの外観のある図 (テキストを含む) をマークアップする

見出しでコンテンツの重要なセクションの始まりが示されるので、支援技術の利用者は見出しのリストにアクセスして、適切な見出しに直接ジャンプし、コンテンツを読み始めることができる。見出しでコンテンツを「ざっと読み」、興味のあるコンテンツに直接移動できるこの機能は、そうしなければコンテンツへのアクセスが遅くなってしまう利用者にとって、操作が非常にスピードアップする。

事例

事例 1: Adobe Acrobat 9 Pro を使用して、PDF 文書内のタグ付き見出しを追加または変更する

Touchup 読み上げ順序ツールを使用する

PDF 文書に見出しを追加する方法の一つとして、Touchup 読み上げ順序ツールを使用できる。

Adobe Acrobat Pro で PDF 文書を開く
アドバンスト > アクセシビリティ > TouchUp 読み上げ順序を選択する
TouchUp 読み上げ順序パネルの［順序パネルを表示］ボタンをクリックする。
［順序］パネルでタグが表示される

次の画像は、Adobe Acrobat Pro で開いた PDF 文書を示している。タグパネルが開き、H1 タグとして「Cooking techniques」、H2 タグとして「Cooking with oil」という見出しテキストが表示されている。「Cooking with butter」というテキストは H2 タグとすべきであるが、H2 タグにはなっていない。

スクリーンショット：Adobe Acrobat で開いた PDF 文書。［タグ］パネルには、タグツリー内の見出しが表示されている。H2 としてタグ付けされるべきテキストが、誤って段落としてタグ付けされている。

H2 見出しに修正するには、次のように TouchUp 読み上げ順序パネルを使用する。

選択ボックスを左クリックして、タグ付けするコンテンツにドラッグする
TouchUp 読み上げ順序パネルから「見出し 2」タグを選択する

次の画像は、Adobe Acrobat Pro で開いた PDF 文書を示している。TouchUp 読み上げ順序パネルが表示されている。「Cooking with butter」テキストの近くに選択ボックスが表示され、パネルの「見出し 2」が選択されている。

スクリーンショット：Adobe Acrobat で開いた PDF 文書。TouchUp 読み上げ順序パネルが表示されている。見出しテキストが選択され、パネルの「見出し 2」が選択されている。

最後に、TouchUp 読み上げ順序パネルの［順序パネルを表示］ボタンを押下する。

次の画像は、Adobe Acrobat Pro で開いた PDF 文書を示している。タグパネルが表示され、H2 としてタグ付けされた「Cooking with butter」というテキストが表示されている。

スクリーンショット：Adobe Acrobat で開いた PDF 文書。TouchUp 読み上げ順序パネルに正しくタグ付けされた見出しが表示されている。

［順序］パネルと［タグ］パネルを使用する

次の手順に従い、見出しを追加または変更することもできる。

［順序］パネルを表示する
変更または追加する見出しのテキストのコンテキストメニューを開く
テキストに対する正しい見出しタグを選択する

次のスクリーンショットは、「Cooking with butter」というテキストの順序パネルとコンテキストメニューを示している。コンテキストメニューから「見出し 2 としてタグ付け」が選択されている。

スクリーンショット：Adobe Acrobat で開いた PDF 文書。順序パネルとコンテキストメニューに、見出し2 に変更するテキストが示されている。

次のスクリーンショットに示すように、タグパネルを開いて、正しい見出しが適用されていることを確認できる。

PDF document opened in Adobe Acrobat. The Tags panel confirms the correct heading tags.

この事例のサンプルとして、タグ付き見出しを追加するサンプル (Word ファイル) とタグ付き見出しを追加するサンプル (PDF ファイル) がある。

事例 2: PDF 変換時に正しいタグ付き見出しのある Microsoft Word 文書を作成する

スタイルを使用して、見出しの書式 (見出し 1、見出し 2、見出し 3 など) を作成する。スタイルが論理的な構成になるようにする (見出し 2 が見出し 1 より後に来るようにするなど)。

Microsoft Word 2003

書式 > スタイルと書式メニューを選択し、［スタイルと書式］ウィンドウを表示する
［スタイルと書式］パネルに用意されている見出し 1～6 のスタイルを使用する

スクリーンショット：Word 2003での見出しの書式の選択

Microsoft Word 2007/2010

Word 2007/2010 で［ホーム］リボンを選択し、スタイルのグループから適切な見出し (見出し 1～6) を選択する。

Word 2007/2010での見出しの書式の選択

事例 3: OpenOffice.org Writer 2.2 で PDF 変換時に正しいタグ付き見出しがある文書を作成する

この事例は OpenOffice.org Writer の場合を示している。同様の機能を実行するソフトウェアツールは他にも存在する。他のソフトウェアツールのリストについては、「アクセシビリティがサポートされている PDF オーサリングツール」を参照のこと。

次の手順に従い、PDF としてエクスポートする。

ファイルメニューの「PDF としてエクスポート」を選択する
初めて PDF としてエクスポートする場合には、オプションダイアログボックスが表示される
「タグ付き PDF」を選択して、［エクスポート］を選択する

スクリーンショット: OpenOffice.org Writer で見出しスタイルを選択し、PDF にエクスポートする。

事例 4: /Hn エレメントを使用して見出しをマークアップする

PDF 文書内の見出しは、構造ツリー内の /Hn エレメントを使用してマークアップできる。ここで、n は 1 ～ 6 の数字である (/H1、/H2 など)。

次のコードフラグメントは、/Hn エレメントを使用してコンテンツをマークアップする一般的なコードを示している。なお、この例においては、/H1 は /Head1 に role がマップされている。これは通常、オーサリングツールを使用して行う。


0 obj% Document catalog
  << /Type /Catalog
     /Pages 100 0 R                  % ページツリー
     /StructTreeRoot 300 0 R         % 構造ツリーのルート
  >>
endobj
 ...
300 0 obj% Structure tree root
  << /Type /StructTreeRoot
     /K [ 301 0 R                    % 二つの子: 章と
        304 0 R                      % 段落
        ]
     /RoleMap << /Chap /Sect         % 構造ツリーへのマッピング
                 /Head1 /H
                 /Para /P
              >>
    /ClassMap << /Normal 305 0 R >>  % 一つの属性クラスを含むクラスマップ
    /ParentTree 400 0 R              % 親エレメントの数字ツリー
    /ParentTreeNextKey 2             % 親ツリーで次に使用するキー
    /IDTree 403 0 R                  % エレメント識別子の名前ツリー
  >>
endobj
301 0 obj                            % 章の構造エレメント
  << /Type /StructElem
     /S /Chap
     /ID (Chap1)                     % エレメント識別子
     /T (Chapter 1)                  % 人間が読み取ることができるタイトル
     /P 300 0 R                      % 親が構造ツリーのルート
     /K [ 302 0 R                    % 二つの子：セクションヘッダーと
          303 0 R                    % 段落
        ]
  >>
endobj
302 0 obj                            % セクションヘッダーの構造エレメント
  << /Type /StructElem
     /S /Head1
     /ID (Sec1.1)                    % エレメント識別子
     /T (Section 1.1)                % 人間が読み取ることができるタイトル
     /P 301 0 R                      % 親が章
     /Pg 101 1 R                     % コンテンツ項目を含むページ
     /A << /O /Layout                % レイアウトが所有する属性
           /SpaceAfter 25
           /SpaceBefore 0
           /TextIndent 12.5
        >>
    /K 0                             % マークされたコンテンツ順序 0
  >>
endobj
...

マークされたコンテンツコンテナー内で、PDF 文書内の第1レベルの見出しに対して、次のように /Headn エレメントを使用して見出しをマークアップできる。


BT		 		% テキストオブジェクトの始まり
  /Head1 <</MCID 0 >>   	% マークされたコンテンツ順序の始まり
     BDC
        ...
        (これは第1レベルの見出しです。Hello world: ) Tj
        ...
     EMC			% マークされたコンテンツ順序の終わり
     ...
ET				% テキストオブジェクトの終わり

参考リソース

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

Section 14.8.4.3.2 (Paragraphlike Elements) in PDF 1.7 (ISO 32000-1)
PDF Accessibility Documentation:headings
PDF and Accessibility

G141: 見出しを用いてウェブページを構造化する

検証

手順

別個のセクションに分割されているすべての PDF コンテンツについて、次のいずれかの方法を使用して、見出しが正しくタグ付けされていることを確認する。
- PDF 文書をスクリーンリーダーで読み上げると、見出しのリストが正しく読み上げられる。
- PDF エディターを使用して、見出しが正しくタグ付けされていることを確認する。
- /Headn エントリを表示できるツールを使用して PDF 文書を開き、見出しが正しくタグ付けされていることを確認する。
- アクセシビリティ API を通じて文書を表示するツールを使用して、見出しが正しくタグ付けされていることを確認する。

期待される結果

1. の結果が真である。

PDF10: PDF 文書内のインタラクティブなフォームコントロールにラベルを付ける

適用 (対象)

フォームが含まれているタグ付き PDF 文書
Adobe LiveCycle Designer で作成された PDF フォーム

これは、次の達成基準に関連する達成方法である:

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

PDF10 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法の目的は、支援技術の利用者がフォームコントロールのラベルを認識し、フォームコントロールの使用方法を理解できるようにすることである。

フォームコントロールを使用すると、利用者は、情報を入力したり選択肢を指定したりして PDF 文書を操作してから、送信して処理することができる。支援技術の利用者は、視力のある利用者と同様に、フォームフィールドを認識して理解し、選択を行い、フォームに入力し、フォームを送信できなければならない。フォームのアクセシビリティを確保するには、各フォームコントロールの目的を示す、理解可能なラベルが不可欠である。

フォームの入力では通常、必要な情報とフォームの入力方法を利用者が理解できるように、ラベルと説明文が提供される。これらのラベルが、対応するフィールドとプログラムで関連付けられていないと、支援技術で正しく関連付けを行うことができず、利用者がフォームの入力方法を理解できないことがある。

インタラクティブなフォームが含まれている文書を Adobe Acrobat Pro を使用して作成することで、プログラムで関連付けられた、フィールドの目的を示すラベルを付けることができ、フォームのアクセシビリティとユーザビリティが確保される。

プログラムで関連付けられたラベルがない場合には、支援技術が使用するヒューリスティック手法によって、テキストラベルが使用される場合がある。フィールド辞書の TU エントリ (ツールヒント) が、プログラムで関連付けられたラベルである (以下の事例 3 と、PDF 1.7 (ISO 32000-1) の表 220 を参照のこと)。そのため、各フィールドにツールヒントを追加し、支援技術が解釈できるラベルを提供する。

配置ルール

次の表は、Adobe LiveCycle によってデフォルトでラベルが配置される場所を規定する、配置ルールを示している。これらのルールでは、テキストの方向が左から右であることが前提になっている。特定のフォームでデフォルトとは異なる配置が必要な場合 (テキストの方向が右から左の言語の PDF に対応する場合など) については、以下の事例 2 のフォームラベルの位置を変更するを参照のこと。一般的に作成者は、特定のフォームの要件を満たすために、ラベルの配置について検討すべきである。

コントロールタイプ	LiveCycle の配置ルール
テキスト入力 (日付／時刻フィールドとパスワードフィールドを含む)	コントロールの左側にラベルを配置する (デフォルト)。不可能な場合、LiveCycle ではコントロールのすぐ上に配置される。
チェックボックス	チェックボックスの右側にラベルを配置する (デフォルト)。
ラジオボタングループ	個々のラジオボタンの右側にラベルを配置する (デフォルト)。ラジオボタングループにキャプションを表示するには、静的なテキストを作成し、グループの左側または上に配置する (下の「ラジオボタンにラベルを付ける」を参照のこと)。
コンボボックス	ドロップダウンリストの左側にラベルを配置する (デフォルト)。不可能な場合、LiveCycle ではコントロールのすぐ上に配置される。
リストボックス	リストボックスの上にラベルを配置する (デフォルト)。
ボタン	LiveCycle では、ラベルは自動的にボタン上に配置される。手動で位置を設定する必要はない。ボタンの目的がラベルテキストに適切に記述されていることを確認する。

事例

事例 1: Adobe Acrobat 9 Pro のフォームツールを使用してラベルを付ける

解説に記載されているように、オーサリングツールで追加され PDF に変換されたテキストラベルは、フィールドに視覚的に関連付けられていても、プログラムで関連付けられていないため、ツールヒントを提供する必要がある。

［フォーム］メニューで［フィールドを追加または編集］を選択する
編集するフィールドのコンテキストメニューから［プロパティ］ダイアログボックスを選択する
［プロパティ］ダイアログボックスの［一般］タブで、「ツールヒント」フィールドにフォームフィールドの説明を入力する
すべてのフォームフィールドについて同じ操作を繰り返す

次の画像は、［プロパティ］ダイアログボックスの「ツールヒント」フィールドに説明が入力された状態を示している。

スクリーンショット: フォームフィールドのプロパティダイアログボックス。フィールドで要求される形式を含む簡単な説明を入力すると、ツールヒントとして表示される。

この事例のサンプルとして、フォームツールを使用してラベルを表示させるサンプル (PDF フォーム) がある。

事例 2: Adobe LiveCycle Designer ES 8.2.1 でフォームコントロールにラベルを付ける

この事例は Adobe LiveCycle Designer の場合を示している。同様の機能を実行するソフトウェアツールは他にも存在する。他のソフトウェアツールのリストについては、「アクセシビリティがサポートされている PDF オーサリングツール」を参照のこと。

LiveCycle Designer には、説明的なテキストやラベルをフォームエレメントに関連付けるためのいくつかのオプションがある。

視力のある利用者またはロービジョンの利用者の場合は、コントロールのすぐ近くにラベルを正しく配置することが重要である。スクリーンリーダーの利用者の場合は、ラベルがフォームコントロールとプログラムで関連付けられていることと、スクリーンリーダーの利用者がすぐにフォームに入力して送信できるだけの十分な情報が提供されていることを確認する必要もある。

この事例のサンプルとして、フォームツールを使用してラベルを提供するサンプル (PDF ファイル) がある。

アクセシビリティパレットを使用してアクセシブルなラベルテキストを指定する

LiveCycle Designer で、フォームを作成またはインポートする。次に、以下の作業を行う。

ウィンドウ > アクセシビリティを選択するか、Shift + F6 キーを押して、パレットを有効にする
LiveCycle Designer の右側のパネルにパレットが表示される
フォーム内のオブジェクトを選択する。パレットに、オブジェクトのアクセシビリティプロパティが表示される。

スクリーンショット：優先順位ドロップダウンリストが表示された Adobe LiveCycle アクセシビリティパレット。テキストは、リストで示される順序（カスタムテキスト、ツールチップ、キャプション、名前）で読み上げられる。

スクリーンリーダーが使用するラベルは、必ずしも視覚的なキャプションと同じである必要はない。フォームエレメントの目的について、より多くの情報を提供する必要がある場合もある。

特定のオブジェクトについてスクリーンリーダーが読み上げるテキストを指定するには、アクセシビリティパレットのスクリーンリーダーの優先順位ドロップダウンリストを使用する。テキストは、リストで示される順序（カスタムテキスト、ツールチップ、キャプション、名前）で読み上げられる。

フォームの複雑さと難しさに応じて、フォームの要件に最も適したオプションを判断する必要がある。

デフォルトでは、スクリーンリーダーは画像で示されている順序でオブジェクトのテキストを検索する。コントロールの説明的なテキストが見つかると、検索は終了する。

次の画像は、スクリーンリーダーのユーザーにとってわかりにくい視覚的なキャプションを持つテキストフィールドの例を示している。一つのフィールドのキャプションは「日付」になっているが、スクリーンリーダーのユーザーは、（スクリーンテキストに示されているような）推奨される日付形式を知る必要がある。このため、このテキストはツールチップで提供される。ツールチップは視覚的なキャプションより優先度が高いため、スクリーンリーダーはツールチップを使用する。

スクリーンショット：日付形式に関するツールヒントテキストが表示された、LiveCycle Designer の日付形式フィールド。

ラジオボタンにラベルを付ける

スクリーンリーダーのユーザーがラジオボタンにタブ移動したとき、スクリーンリーダーは次の二つの項目を読み上げる必要がある。

ボタンのグループの目的に関する一般的な説明
それぞれのラジオボタンの目的に関する意味のある説明

ラジオボタンをアクセシブルにするには：

［階層］パレットで、ラジオボタングループを選択する
［アクセシビリティ］パレットを選択し、「カスタムのスクリーンリーダーテキスト」ボックスに、グループに対する読み上げテキストを入力する。例えば、「支払方法を選択してください」と入力する
［階層］パレットで、グループの最初のラジオボタンを選択する
［オブジェクト］パレットで、［フィールド］タブを選択する。「項目」領域で項目を選択し、選択したラジオボタンに対する意味のある値を入力する。例えば、「現金」と入力する
グループ内のラジオボタンごとに、手順 3 と 4 を繰り返す

スクリーンショット：LiveCycle Designer でラジオボタンに適用するカスタムのスクリーンリーダーテキスト。

フォームラベルの位置を変更する

ユーザーは、キャプション（ラベル）がコントロールのすぐ近くの特定の場所にあることを想定しているので、これらの配置は重要である。画面拡大表示機能のユーザーの場合、コントロールとラベルを同時に表示できない可能性があるため、この点は特に重要となる。

オブジェクトを作成すると、Adobe LiveCycle Designer はコントロールタイプで指定されたとおりにラベルの位置を自動的に設定する（上の「解説」の表を参照のこと）。例えばテキストフィールドでは、コントロールの左側にラベルを配置する。

ラベルテキストの配置を変更する場合（テキストの方向が右から左の言語に対応するためなど）には、次の操作を行う。

オブジェクトにフォーカスを移動して、オブジェクトを選択する
［レイアウト］パレットの「キャプション」で、「位置」ドロップダウンリストからオブジェクトの位置を選択する

スクリーンショット：レイアウトパレットと新しいキャプションの位置

この操作の結果、位置が変更されたラベルを以下に示す。日付テキストフィールドのラベルが、フィールドの左側からフィールドの上に移動している。

スクリーンショット：フォームラベルの位置がフィールドの上に変更された。ラベルのデフォルトの位置（テキストフィールド左側）も示されている。

事例 3: インタラクティブなフォームコントロールにツールヒントを追加する

次のコードフラグメントは、TU エントリを使用してフォームフィールドにツールヒント (またはプログラムで関連付けられたテキストラベル) を追加する方法を示している。これは通常、オーサリングツールを使用して行う。

<< /AP -dict-                                                   
   /DA /Helv  0 Tf 0 g
   /DR -dict-
   /F 0x4
   /FT Tx              % テキストフィールドの Tx に設定された FT キー
   /P -dict-
   /Rect -array-
   /StructParent 0x1
   /Subtype Widget
   /T Date you are available   % 日付の部分的なフィールド名
   /TU Date you are available: use MM/DD/YYYY format % 簡単な説明として機能する TU ツールヒントの値
   /Type Annot
   /V Pat Jones
>>
...
<Start Stream>
 BT
  /P <</MCID 0 >>BDC
  /CS0 cs 0  scn 
  /TT0 1 Tf
    -0.001 Tc 0.003 Tw 11.04 0 0 11.04 72 709.56 Tm
    [(P)-6(le)-3(as)10(e)-3( )11(P)-6(rin)2(t)-3( Y)8(o)-7(u)2(r N)4(a)11(m)-6(e)]TJ
  0 Tc 0 Tw 9.533 0 Td
  ( )Tj
  -0.004 Tc 0.004 Tw 0.217 0 Td
  [(\()-5(R)-4(e)5(q)-1(u)-1(i)-3(r)-3(e)-6(d)-1(\))]TJ
 EMC
  /P <</MCID 1 >>BDC
  0 Tc 0 Tw 4.283 0 Td
  [( )-2( )]TJ
   EMC
   /ArtifactSpan <</MCID 2 >>BDC
   0.002 Tc -0.002 Tw 0.456 0 Td
  [(__)11(___)11(___)11(___)11(___)11(_)11(____)11(___)11(___)11(__)]TJ
  0 Tc 0 Tw 13.391 0 Td
  ( )Tj
  EMC
 ET
<End Stream>

参考リソース

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

検証

手順

各フォームコントロールについて、コントロールに関連付けられた正しい位置にラベルが配置されている。
各フォームコントロールについて、次のいずれかの方法で、名前がコントロールにプログラムで関連付けられていることを確認する:
- コントロールに関連付けられている名前を表示できるツールを使用して PDF 文書を開き、名前がコントロールに正しく関連付けられていることを確認する。
- アクセシビリティ API を通じて文書を表示するツールを使用して、名前がコントロールに正しく関連付けられていることを確認する。

期待される結果

1. 及び 2. の結果が真である。

PDF11: PDF 文書内で Link アノテーションと /Link 構造要素を使用してリンクとリンクテキストを提供する

適用 (対象)

リンクを含む PDF 文書

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する
達成基準 2.1.1 (キーボード)
- クイックリファレンス 2.1.1 (キーボード)
- 達成基準 2.1.1 (キーボード)を理解する
達成基準 2.1.3 (キーボード (例外なし) )
- クイックリファレンス 2.1.3 (キーボード (例外なし) )
- 達成基準 2.1.3 (キーボード (例外なし) )を理解する
達成基準 2.4.4 (リンクの目的 (コンテキスト内) )
- クイックリファレンス 2.4.4 (リンクの目的 (コンテキスト内) )
- 達成基準 2.4.4 (リンクの目的 (コンテキスト内) )を理解する
注記: この達成方法は、達成基準 2.4.4 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 2.4.4 を理解するを参照すること。
達成基準 2.4.9 (リンクの目的 (リンクのみ) )
- クイックリファレンス 2.4.9 (リンクの目的 (リンクのみ) )
- 達成基準 2.4.9 (リンクの目的 (リンクのみ) )を理解する

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

PDF11 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法の目的は、キーボードおよび支援技術の利用者が認識できるように PDF 文書内のリンクテキストをマークアップする方法を示すことである。つまり、リンクが別の形式で表示されたときに認識可能であるように、リンク情報をプログラム的に利用可能にする。これは通常、PDF のオーサリングツールを使用して行う。

PDF 文書内のリンクは、そのサブツリー内のリンクタグおよびオブジェクトで表わされ、リンクオブジェクト参照 (リンク注釈) と一つまたは複数のテキストオブジェクトで構成される。リンクタグ内のテキストオブジェクトまたはオブジェクトは、リンクの名前を提供するために支援技術で使用される。

WCAG 達成基準に適合するリンクを提供する最も容易な方法は、PDF に変換する前の、文書をオーサリングする段階でリンクを作成することである。

ただし、元のオーサリングツールを使用してリンクを作成することができない場合もある。そのような場合は、Adobe Acrobat Pro を使用してリンクを作成することができる。ただし、Adobe Acrobat Pro のリンクダイアログボックスを使用して作成したツールヒントは、スクリーンリーダーからアクセスできないため、そのリンクテキストまたはリンクの文脈で目的を明確にすること。

いかなる場合でも、次の一般的なテクニックで説明されているように、リンクの目的を明確にする必要がある。

事例

事例 1: PDF に変換する前に Microsoft Word 2007 でハイパーリンクを作成する

Microsoft Word でハイパーリンクを作成するには、まずリンク先の項目 (Web ページなど) を特定する。次に、以下の作業を行う。

次のいずれかの作業を行う
- リボン上にある「挿入」を選択し、リンクツールの「ハイパーリンク」を選択する/p>
- Ctrl + K キーボードショートカットを使用する
ハイパーリンクの挿入ダイアログボックスで、リンク先とリンクテキストを追加する
タグ付き PDF としてファイルを保存する (「PDF テクノロジーノート」を参照のこと)

事例 2: PDF に変換する前に OpenOffice.org Writer 2.2 でハイパーリンクを作成する

この事例は OpenOffice.org Writer の場合を示している。同様の機能を実行するソフトウェアツールは他にも存在する。他のソフトウェアツールのリストについては、「アクセシビリティがサポートされている PDF オーサリングツール」を参照のこと。

［挿入］メニューの［ハイパーリンク］を選択する
［ハイパーリンク］ダイアログボックスで、「ハイパーリンクの種類」の「ターゲット」フィールドにリンク先の URI を挿入する
「詳細設定」の「テキスト」フィールドにリンクテキストを挿入する (このダイアログボックスを表示する前に、文書のテキストからリンクテキストを選択することもできる。選択したテキストが「テキスト」フィールドに挿入される)
タグ付き PDF としてファイルを保存する (「PDF テクノロジーノート」を参照のこと)

事例 3: Adobe Acrobat 9 Pro でリンクの作成ダイアログボックスを使用してハイパーリンクを作成する

リンクテキストにするテキストを選択する
コンテキストメニューから［リンクの作成］を選択する

スクリーンショット: ハイパーリンクを作成するためにテキストが選択されている PDF 文書。コンテキストメニューで［リンクの作成］が選択されている。

3. リンクの作成ダイアログボックスの指示に従い、以下に示されているように、リンクの外観を指定する

スクリーンショット: リンクの作成ダイアログボックスが開き、「リンクの外観」のオプションが選択されている PDF 文書。

「次へ」を選択し、URI を指定する。次の画像は、結果として表示されるハイパーリンクとツールヒントを示している。

スクリーンショット: リンクの作成ダイアログボックスを使用して作成されたハイパーリンクがあり、マウスオーバーによりツールヒントが表示されている PDF 文書。

この事例のサンプルとして、PDF でハイパーリンクを作成したサンプル (PDF ファイル) がある。

事例 4: /Link 構造エレメントを使用してリンクテキストをマークアップする

PDF 文書内のリンク注釈は、コンテンツストリームの特定のオブジェクトではなくページの幾何学的領域に関連付けられる。このため、リンク注釈は単独では、視覚障害のある利用者、またはハイパーテキストリンクを起動するためにどのコンテンツをアクティブ化できるのかを判断する必要のあるアプリケーションにとって有用ではない。

タグ付き PDF の /Link エレメントは、PDF の論理構造を使用してコンテンツ項目とリンク注釈の間の関連付けを確立し、HTML ハイパーテキストリンクに相当する機能を提供する。

HTML の場合、次の事例はハイパーテキストリンクを含むテキストを生成する。

Here is some text <a href="http://www.w3.org/WAI/"> with a link </a> inside.

PDF の場合、最初にページが表現され、オブジェクトアクションが発生する領域にリンク注釈が配置される必要がある。

次のコードフラグメントは、アンダーラインの付いた青色で表示されるリンクテキストを使用する、上述の HTML に相当する PDF を示している。次に続く 2 番目のコードフラグメントは、関連付けられた論理構造階層を示している。これは通常、オーサリングツールを使用して行う。

 /P <</MCID 0>>                                                % マークされたコンテンツ順序 0 (段落)
  BDC                                                          % マークされたコンテンツ順序の始まり
   BT                                                          % テキストオブジェクトの始まり
    /F1 11.04 Tf                                               % テキストのフォントおよびサイズの設定
    1 0 0 1 72.024 709.54 Tm                                   % テキストマトリクスの設定
    0 g                                                        % ストローク以外の色を黒に設定
    0 G                                                        % ストロークの色を黒に設定
   [(H)3(ere )-4(is s)10(o)5(m)-4(e)9( t)-3(e)9(xt)-3( )] TJ   % リンク " Here is some text" の前にテキストを表示
   ET                                                          % テキストオブジェクトの終わり
  EMC                                                          % マークされたコンテンツ順序の終わり
 
 /Span <</MCID 1>>                                             % マークされたコンテンツ順序 1 (下線付きのリンクテキスト)
  BDC                                                          % マークされたコンテンツ順序の始まり
   BT                                                          % テキストオブジェクトの始まり
    1 0 0 1 152.42 709.54 Tm                                   % テキストマトリクスの設定
    0 0 1 rg                                                   % ストローク以外の色を青に設定
    0 0 1 RG                                                   % ストロークの色を青に設定
    [(with a )-2(li)3(n)14(k)] TJ                              % リンクテキスト " with a link" の表示
   ET                                                          % テキストのオブジェクトの終わり
    0 0 1 rg                                                   % ストロークの色を青に設定
    152.42 707.62 45.984 0.72 re                               % 長方形のオペレータ - リンクの対象領域
    f*                                                         % 偶数奇数ルールを使用してパスを塗りつぶす
  EMC                                                          % マークされたコンテンツ順序の終わり
 
 /P <</MCID 2>>                                                % マークされたコンテンツ順序 2 (段落)
  BDC                                                          % マークされたコンテンツ順序の始まり
   BT                                                          % テキストオブジェクトの始まり
    1 0 0 1 198.41 709.54 Tm                                   % テキストマトリクスの設定                                             
    0 g                                                        % ストローク以外の色を黒に設定
    0 G                                                        % ストロークの色を黒に設定
    [( )] TJ                                                   % テキストストリングを空にして空白を表示
   ET                                                          % テキストオブジェクトの終わり
   BT                                                          % テキストオブジェクトの始まり
    1 0 0 1 200.93 709.54 Tm                                   % テキストマトリクスの設定
    [(in)5(sid)5(e.)] TJ                                       % リンクの後にテキスト "inside." を表示
   ET                                                          % テキストの終わり
   BT                                                          % テキストオブジェクトの始まり
    1 0 0 1 229.97 709.54 Tm                                   % テキストマトリクスの設定
    [( )] TJ                                                   % テキストストリングを空にして空白を表示
   ET                                                          % テキストオブジェクトの終わり
  EMC                                                          % マークされたコンテンツ順序の終わり

次のコードフラグメントは、コンテンツ項目とリンク注釈の間の関連付けを確立する論理構造からの抜粋である。

 11 0 obj                                              % オブジェクト ID 11、生成 0、obj キーワード
  <</K[1                                               % 構造ツリールートの直接の子
   <<
    /Obj 26 0 R                                        % 26 への参照
    /Type/OBJR                                         % このオブジェクトは間接的なオブジェクト参照を表す
   >>]
    /P 12 0 R
    /Pg 17 0 R
    /S/Link
  >>
 endobj
 
 26 0 obj                                              % オブジェクト 11 内の OBJR によって参照されるオブジェクト ID 26
  <</A 31 0 R
   /BS
   <</S/S
     /Type/Border
     /W 0
   >>
   /Border[0 0 0]                                      % 色なし境界線
   /H/I
   /Rect[150.128 694.558 200.551 720.0]                % リンク注釈がアクティブな対象領域を定義する境界
   /StructParent 1
   /Type/Annot                                         % 構造エレメントは注釈
   /Subtype/Link
  >>                                                           % リンク注釈                                                 
 endobj     
 31 0 obj                                              % オブジェクト 31、生成 0、obj
  <</S/URI                                             % オブジェクトタイプは URI アクション
    /URI(http://www.w3.org/WAI)                        % 解決する URI
  >>   
 endobj

参考リソース

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

Section 14.8.4.4.2 (Link Elements) in PDF 1.7 (ISO 32000-1)
PDF and Accessibility

検証

手順

各ハイパーリンクについて、リンクが正しくタグ付けされており、リンクテキストが適切に表示されることを確認する。

PDF 文書をスクリーンリーダーで読み上げると、リンクが正しく読み上げられ、リンクの目的 (例えば、リンク先) が説明されている。
タグツリーを視覚的にスキャンすると、リンクが正しくタグ付けされ、(スクリーン拡大鏡の利用者と、認知障害があるが視力のある利用者向けに) リンクテキストが表示される。
/Link エントリ値を表示できるツールを使用して PDF 文書を開き、ハイパーリンクとリンクテキストを表示する。
アクセシビリティ API を通じて文書を表示するツールを使用し、リンクに正しいリンクテキストがあることを確認する。
各リンクにタブ移動し、Enter を押すことによりそのリンク先にアクセスできる。

期待される結果

1. 又は 2. 又は 3. 又は 4. の結果が真である。
5. が真である。

PDF12: PDF 文書内のフォームフィールドの名前 (name)、役割 (role)、値 (value) 情報を提供する

適用 (対象)

インタラクティブなフォームフィールドが含まれているタグ付き PDF 文書

これは、次の達成基準に関連する達成方法である:

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

PDF12 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法の目的は、支援技術で PDF コンテンツ内のフォームコントロールに関する情報を収集し、そのフォームコントロールと対話することである。

PDF フォームコントロールの種類は、テキスト入力フィールド、チェックボックス、ラジオボタン、コンボボックス、リストボックスおよびボタンである。

名前、役割、状態および値情報をすべてのフォームコンポーネントに提供することにより、障害のある人が使用するスクリーンリーダー、画面拡大ソフトウェア、音声認識ソフトウェアなどの支援技術との互換を可能にする。

PDF 仕様は、以下の表に示されているように、「PDF 1.7 (ISO 32000-1)」の節 12.7.4 (Field Types) でフォームコントロールに対して名前、役割および値が設定される方法を定義する。コメント列では、対応する情報を Adobe Acrobat Pro で表示する方法について説明する。

インタラクティブなフォーム辞書エントリ	定義する項目	コメント
FT	役割 (role)	フィールドの種類を共有し、フィールドフラグを使用して適切な役割を設定するコントロール。Adobe Acrobat では、フォームコントロールの役割は自動的に設定される。
TU	名前 (name)	Adobe Acrobat では、TU エントリ値は、フォームコントロールのプロパティダイアログボックスのツールヒントフィールドを通じて提供される。このエントリは、Acrobat のフォームコントロールのプロパティダイアログボックスで名前として定義される T エントリと混同しないこと。このプロパティダイアログボックスの「名前」フィールドは、支援技術により読み取られる際にコントロールの名前を提供するためには使用されない。
CA	名前 (name) (プッシュボタンのみ)	Adobe Acrobat では、CA エントリ値は、フォームコントロールのプロパティダイアログボックスのラベルフィールドを通じて提供される。
V	値	値エントリは、値を必要とするコントロールと対話する利用者により設定される。
DV	デフォルト値	Adobe Acrobat では、DV エントリ値はフォームコントロールのプロパティダイアログボックスで設定できる。

以下の表では、Adobe Acrobat Pro を使用して作成される PDF フォームコントロールに対して役割、名前、値および状態がどのように定義されるのかを説明する。Adobe LiveCycle Designer には、これらと同様のコントロールと、いくつかの追加のコントロールが用意されている。(後述の事例 2 を参照のこと)。

PDF フォームエレメント	役割 (FT エントリ)	名前 (name) (TU エントリ)	値 (V エントリ)	設定可能な状態
テキストフィールド	テキスト `/Tx`	ツールチップ	デフォルト値 (フィールド辞書の DV エントリ) はプロパティダイアログボックスで設定できる。値は利用者により入力される。	Read Only, Required, Multiline, Password
チェックボックス	チェックボックス　`/Btn`	ツールチップ	V エントリは、Checked 状態に応じて「Yes」または「No」に設定される。	Read Only, Required, Checked
ラジオボタン	ラジオボタン　`/Btn` (フィールドフラグを「Radio」に設定する)	ツールチップ	V エントリは、Checked 状態に応じて「Yes」または「No」に設定される。	Read Only, Required, Checked
コンボボックス	コンボボックス　`/Ch` (フィールドフラグを「Combo」に設定する)	ツールチップ	デフォルト値 (/DV) はプロパティダイアログボックスで設定できる。値は利用者の選択によって決定される。	Read Only, Required
リストボックス	ドロップダウンリスト　`/Ch`	ツールチップ	デフォルト値 (/DV) はプロパティダイアログボックスで設定できる。値は利用者の選択によって決定される。	Read Only, Required
ボタン	プッシュボタン　`/Btn` (フィールドフラグを「Pushbutton」に設定する)	ラベル (TU エントリではなく CA エントリ)	プッシュボタンは値を持たず、必要としない。	Read Only, Required
署名フィールド	テキスト　`/Sig`	ツールチップ	デフォルト値 (フィールド辞書の DV エントリ) はプロパティダイアログボックスで設定できる。値は利用者により入力される。	Read Only, Required

事例

事例 1: Adobe Acrobat 9 Pro を使用してフォームフィールドの名前、役割、値、状態を指定する

この事例では、説明のためにチェックボックスを使用する。手順はその他のフォームコントロールと同様である。フォーム編集モードで、次の操作を行う。

作成または変更するフォームフィールドのコンテキストメニューにアクセスする
フォームフィールドの［プロパティ］ダイアログボックスを選択する
「ツールヒント」フィールドに値を追加して名前を指定する。これは、コントロールの名前としてアクセシビリティ API により使用され、通常、コントロールの視覚的なラベルとして使用されるテキストと一致するように設定する必要がある
［オプション］タブを選択する
必要に応じて、デフォルト値とデフォルトの状態を指定する

以下の画像は、［一般］タブが表示されている、チェックボックスのプロパティダイアログボックスを示している (ダイアログボックス内の「名前」フィールドはアクセシビリティでは必要ない)。

スクリーンショット: チェックボックスの「名前」フィールドと「ツールヒント」フィールドが表示されている、［チェックボックスのプロパティ］ダイアログボックスの［一般］タブ

以下の画像は、［オプション］タブが表示されている、［チェックボックスのプロパティ］ダイアログボックスを示している

スクリーンショット: チェックボックスの値フィールドと状態フィールドが表示されている、［チェックボックスのプロパティ］ダイアログボックスの［オプション］タブ

この事例のサンプルとして、Acrobat Pro を使用して名前 (name)、役割 (role)、値 (value) を指定したサンプル (PDF ファイル) がある。

事例 2: Adobe LiveCycle Designer ES 8.2.1 を使用してフォームフィールドの名前、値および状態を指定する

Adobe LiveCycle Designer では、オブジェクトライブラリを使用してフォームオブジェクトを作成し、オブジェクトパレットを使用してオブジェクトの名前、役割、状態または値を指定する。

次の画像は、［オブジェクト］パレットを示している。

スクリーンショット: フォームの作成に使用できるフォームオブジェクトが表示されている、LiveCycle Designer オブジェクトライブラリ

以下の三つの画像は、オブジェクトパレットの各タブを示している。一つ目の画像では、フィールドの種類 (役割) を指定するための「フィールド」タブが開かれている。

スクリーンショット: LiveCycle Designer オブジェクトパレットの［フィールド］タブ

次の画像は、フィールドに適用できるオプションのある［値］タブを示している。

LiveCycle Designer オブジェクトパレットの「値」タブのオプション

三つ目の画像は、フィールドの名前を指定する［連結］タブを示している。

LiveCycle Designer オブジェクトパレットの［連結］タブ

この事例のサンプルとして、LiveCycle Designer を使用して名前 (name)、役割 (role)、値 (value) を指定したサンプル (PDF ファイル) がある。

事例 3: /Btn フィールドの種類を使用して PDF 文書内にチェックボックスを追加する

次のコードフラグメントは、事例 1 および 2 に示すような単純なチェックボックスフィールドで一般的に使用されるコードを示している。このコードは通常、オーサリングツールにより実行される。


1 0 obj
  << /FT /Btn     % 役割
     /TU Retiree  % 名前
     /V /Yes      % 値
     /AS /Yes
     /AP << /N << /Yes 2 0 R /Off 3 0 R>>
  >>
endobj

参考リソース

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

Section 12.7.4 (Field Types) of PDF 1.7 (ISO 32000-1)
Adobe XML Forms Architecture (XFA)
PDF and Accessibility

検証

手順

フォームコントロールについて、名前 (name)、役割 (role)、値 (value) /状態が次のいずれかによって指定されていることを確認する。
- スクリーンリーダーを使用してフォームコントロールに移動し、そのフォームコントロールをアクティブ化できる、またはその値を変更できる。名前 (name) (ツールヒント) と役割 (roke) が読み上げられる。
- フォームフィールド情報を表示できるツールを使用して PDF 文書を開くと、フォームコントロールに正しい名前 (name)、役割 (role)、値 (value) および状態 (該当する場合) の情報がある。
- アクセシビリティ API を通じて文書を表示するツールを使用して、フォームコントロールに正しい名前 (name)、役割 (role)、値 (value) および状態 (該当する場合) の情報があることを確認する。

期待される結果

1. の結果が真である。

PDF13: PDF 文書内のリンクに対して /Alt エントリを使用して置換テキストを提供する

適用 (対象)

リンクを含むタグ付きPDF文書

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.4 (リンクの目的 (コンテキスト内) )
- クイックリファレンス 2.4.4 (リンクの目的 (コンテキスト内) )
- 達成基準 2.4.4 (リンクの目的 (コンテキスト内) )を理解する
注記: この達成方法は、達成基準 2.4.4 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 2.4.4 を理解するを参照すること。
達成基準 2.4.9 (リンクの目的 (リンクのみ) )
- クイックリファレンス 2.4.9 (リンクの目的 (リンクのみ) )
- 達成基準 2.4.9 (リンクの目的 (リンクのみ) )を理解する

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

PDF13 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法の目的は、タグのプロパティリストにある /Alt エントリを通じて、代替リンクテキストを提供することである。これは通常必要ないものであるが、特にスクリーンリーダーの利用者用に視覚的リンクテキスト以外の追加情報が必要になる場合がある。スクリーンリーダーは視覚的リンクテキストを読み上げることができるが、PDF 文書内のリンクのスクリーンテキストを意味のある代替テキストに置き換えることで、リンクをよりアクセシブルなものにすることができる。

コンテンツ制作者は、リンクタグに対して /Alt エントリを提供することにより、デフォルトリンクテキストを置き換えることができる。リンクタグに /Alt エントリがある場合、スクリーンリーダーはリンクタグ内の視覚的テキストオブジェクトの値を無視し、リンクテキストに /Alt エントリ値を使用する。

WCAG 2.0 達成基準に適合する、文脈に依存しないリンクテキストを提供する最も容易な方法は、PDF に変換する前の、文書をオーサリングする段階でリンクを作成することである。元のオーサリングツールを使用してリンクを作成することができない場合もある。Adobe Acrobat Pro を使用して PDF 文書を編集する場合、アクセシブルなリンクを作成する最善の方法は、「リンクの作成」コマンドを使用することである。

コンテンツ制作者は、リンクの前後にあるスクリーンテキストの文脈において代替テキストが意味をなしていることを確認する必要がある。

事例

事例 1: Adobe Acrobat 9 Pro を使用して代替リンクテキストを追加する

以下の画像は、Oracle Open Office から PDF に変換される文書を示している。視覚的リンクテキストは、リンク先の URL であることに注意すること。スクリーンリーダーはリンクテキストとして URI 全体を読み上げる。

スクリーンショット: リンクテキストとしてリンク URI が含まれている文書

支援技術向けに、よりアクセシブルなリンクテキストを作成するには、以下の操作を行う。

［表示］メニューから、ナビゲーションパネル > タグを選択して［タグ］パネルを開く
タグツリー内で Link タグを見つけ、そのリンクのコンテキストメニューにアクセスして、［プロパティ］を選択する。
［TouchUp のプロパティ］ダイアログボックスの［タグ］タブにある「代替テキスト」フィールドに、代替テキストを入力する。スクリーンリーダーは、URI 全体ではなくこのテキストを読み上げる

次の画像は、［タグ］パネル内での Link タグの構造を示している

スクリーンショット: タグパネル内のリンクタグ構造

最後の画像は、Link タグの［TouchUp のプロパティ］ダイアログボックス内で指定されている代替テキストを示している。スクリーンリーダーはリンクテキストとして代替テキストを読み上げる。

スクリーンショット:［TouchUp のプロパティ］ダイアログボックスで指定された新しい代替テキスト 'Boston Globe technology page'

この事例のサンプルとして、代替リンクテキストを追加したサンプル (OpenDocument テキストファイル) と代替リンクテキストを追加したサンプル (PDF ファイル)がある。

事例 2: /Alt エントリを使用して PDF 文書内に代替リンクテキストを追加する

次のコードフラグメントは、リンクの代替テキストで一般的に使用されるコードを示している。これは通常、オーサリングツールを使用して行う。


32 0 obj
<<
  /S/URI                                       % アクションタイプ (必須)、URI アクションの URI である必要がある
  /URI(http://www.boston.com/business/technology/)  % URI (必須)、解決する URI
>>
endobj

以下は、前述のリンク内の URL に対して代替テキストを指定する方法を示している。

11 0 obj
<<
  /Alt(Boston Globe technology page)    % 代替テキストエントリ
  /K [ 1                                                      
       <<
         /Obj 27 0 R
         /Type /OBJR            % リンクへのオブジェクト参照
       >>
       ]                       
  /P 12 0 R
  /Pg 18 0 R
  /S
  /Link
>>
endobj

参考リソース

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

Section 14.9.4 (Replacement Text) in PDF 1.7 (ISO 32000-1)
PDF and Accessibility

検証

手順

ハイパーリンクについて、代替リンクテキストが次のいずれかの方法で適切にコード化されていることを確認する。
- PDF 文書をスクリーンリーダーで読み上げると、代替テキストが正しく読み上げられる。
- /Alt エントリを表示できるツールを使用して PDF 文書を開き、ハイパーリンクと代替リンクテキストを表示する。
- アクセシビリティ API を通じて文書を表示するツールを使用し、代替リンクテキストがリンクに関するテキストであることを確認する。

期待される結果

1. の結果が真である。

PDF14: PDF 文書内に連続するヘッダーとフッターを提供する

適用 (対象)

タグ付き PDF 文書

これは、次の達成基準に関連する達成方法である:

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

PDF14 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法の目的は、ページネーションアーティファクトを通じて、連続するヘッダーとフッターを提供することにより、利用者が文書内の現在位置を確認できるよう支援することである。これは通常、PDF のオーサリングツールを使用して行う。

連続するヘッダーとフッターは、一貫性のある予測可能な方法で繰り返される情報を提供することにより、コンテンツの利用と理解を容易にするために役立つ。ヘッダーとフッターのコンテンツは、文書の範囲と内容、対象読者および設計上の決定によって大きく異なる。ヘッダーとフッターで使用される現在位置情報の事例のいくつかを以下の一覧に示す。情報がヘッダーに現れるのかフッターに現れるのかは、設計上の決定である場合が多い。ページ番号は、多くの場合フッターにあるが、ヘッダーにあってもかまわない。

文書のタイトル
文書内の現在の章および節
「ページ 3-4」または「ページ 9/15」のような現在位置情報のあるページ番号
作成者および日付情報

一貫性は、認知障害のある利用者、スクリーンリーダーの利用者、ロービジョン拡大鏡の利用者および知的障害のある利用者がコンテンツを理解しやすくするために役立つ。

ページヘッダーとフッターを提供する最も容易な方法は、文書のオーサリングツール内で行う方法である。オーサリングツールは通常、ヘッダーおよびフッターテキストと情報 (ページ番号など) を作成するための機能を提供する。ただし、文書を PDF に変換した後でページヘッダーおよびフッターを追加または変更する必要がある場合、Adobe Acrobat Pro のヘッダーとフッターのツールのようなオーサリングまたは修正ツールを使用することができる。いかなる場合でも、ツールは一貫性のある予測可能なレイアウト、形式およびテキストでページヘッダーおよびフッターを生成する。

事例

事例 1: Microsoft Word 2007 を使用して連続するヘッダーとフッターを追加する

Microsoft Word で、以下の画像に示されているように、ヘッダー、フッター、ページ番号情報およびレイアウトを指定できる挿入リボンを使用する。

スクリーンショット：Word の挿入リボン上にあるヘッダーおよびフッターツール

次の画像に示されているように、これらのツールを使用してヘッダーとフッターを指定することができる。

スクリーンショット：Word 文書内のページヘッダー

スクリーンショット：Word 文書内のページフッター

PDF への変換時に、ページヘッダーおよびフッターが文書内に表示される。

スクリーンショット：Word から変換されたページヘッダー

スクリーンショット：Word から変換されたページフッター

この事例のサンプルとして、Word を使用して連続するヘッダーを追加したサンプル (Word ファイル) と Word を使用して連続するヘッダーを追加したサンプル (PDF ファイル)がある。

事例 2: OpenOffice.org Writer 2.2 を使用して連続するヘッダーとフッターを追加する

この事例は OpenOffice.org Writer の場合を示している。同様の機能を実行するソフトウェアツールは他にも存在する。他のソフトウェアツールのリストについては、「アクセシビリティがサポートされている PDF オーサリングツール」を参照のこと。

OpenOffice.org Writer で、以下の画像に示されているように、ヘッダーおよびフッター情報とレイアウトを指定できる挿入 > ヘッダーツールと挿入 > フッターツールを使用する。

スクリーンショット：OpenOffice.org Writer のヘッダーツールとフッターツール

スクリーンショット：OpenOffice.org Writer 文書内のページヘッダー

スクリーンショット：OpenOffice.org Writer 文書内のページフッター

PDF への変換時に、ページヘッダーおよびページフッターは、事例 1 で変換された Word 文書で設定したように文書内に表示される。

この事例のサンプルとして、OpenOffice Writer を使用して連続するヘッダーを追加したサンプル (OpenOffice ファイル) と OpenOffice Writer を使用して連続するヘッダーを追加したサンプル (PDF ファイル)がある。

事例 3: Adobe Acrobat 9 Pro を使用して PDF 文書に連続するヘッダーとフッターを追加する

Adobe Acrobat Pro で、ヘッダーとフッターを追加したり変更したりできる。

文書 > ヘッダーとフッター > 追加を選択する
ヘッダーとフッターの追加ツールで、文書内のヘッダーとフッターのテキストと形式を指定する
「プレビュー」を使用して、文書のテキスト、フォントおよびレイアウトが望み通りになっていることを確認する

次の画像は、Acrobat Pro のヘッダーとフッターの追加ツールを示している。

スクリーンショット：Adobe Acrobat Pro のヘッダーとフッターの追加ツール

事例 4: /Artifact タグまたはプロパティリストを使用して、PDF 文書内で連続するヘッダーまたはフッターをページネーションアーティファクトとしてマークする

PDF 仕様を使用すると、PDF 1.7 (ISO 32000-1)の節 14.8.2.2 "Real Content and Artifacts" で定義されているように、連続するヘッダーとフッターを「ページネーションアーティファクト」としてマークできるようになる。

アーティファクトは、/Artifact タグと共に、マークされたコンテンツ順序に含められることで実際のコンテンツと明示的に区別される。


/Artifact
BMC
...
EMC

または


/Artifact propertyList
BDC
...
EMC

前者は一般的なアーティファクトを特定するために使用され、後者はプロパティリストが関連付けられているアーティファクトで使用される。注記: テキストのリフローを可能にするために、アーティファクトは可能な限りプロパティリストを関連付けて定義すべきである。境界ボックスが指定されていないアーティファクトは、リフロー中に削除される可能性がある。

アーティファクトのプロパティリストのエントリには、Type、BBox、Attached、Subtype などがある。

参考リソース

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

Section 14.8.2.2 (Real Content and Artifacts) in PDF 1.7 (ISO 32000-1)
PDF and Accessibility

検証

手順

連続するヘッダーおよびフッターが提供されていて、利用者が文書内での現在位置を確認するために役立つ情報 (ページ番号または章番号など) が含まれている。
連続しているヘッダーまたはフッターでセクションヘッダーが使用されている場合、セクションヘッダーと連続しているヘッダーまたはフッターに一貫性がある。

期待される結果

1. 及び 2. の結果が真である。

PDF15: PDF フォームで送信フォームアクションのある送信ボタンを提供する

適用 (対象)

フォームが含まれているタグ付き PDF 文書

これは、次の達成基準に関連する達成方法である:

達成基準 3.2.2 (入力時)
- クイックリファレンス 3.2.2 (入力時)
- 達成基準 3.2.2 (入力時)を理解する

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

PDF15 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法の目的は、PDF フォームの送信フォームアクションを使用して、利用者が明示的に文脈の変更を要求できるメカニズムを提供することがある。送信ボタンの使用目的は、フォームに入力されたデータを送信する HTTP 要求を生成することなので、送信ボタンは文脈を変更するための適切なコントロールである。PDF 文書の送信ボタンは通常、PDF のオーサリングツールを使用して実装される。

事例 1 および 2 は、特定のオーサリングツールを使用して送信ボタンを追加する方法を示している。同様の機能を実行する PDF ツールは他にも存在する。「アクセシビリティがサポートされている PDF オーサリングツール」により提供される機能を参照のこと。

事例

事例 1: Adobe Acrobat 9 Pro を使用して送信ボタンを追加する

ツールバーからフォーム > フォームツール > ボタンを選択し、フォーム上にボタンを作成する
ボタンのコンテキストメニューから「プロパティ」を選択し、［ボタンのプロパティ］ダイアログボックスを開く
［一般］タブで、ボタンのツールヒントを入力する
［オプション］タブで、ボタンラベルかアイコンイメージまたはその両方に対して、レイアウトメニューのオプションを選択する。次に、ボタンを送信ボタンとして指定するために「ラベル」ボックスにテキストを入力したり、「アイコンを選択」をクリックして、使用するイメージファイルを配置したりする
［アクション］タブで次の操作を行う
- 「トリガを選択」で「マウスアップ」を選択する (Mouse Up イベントは、キーボードでアクセス可能である。また、Mouse Up イベントでは、Mouse Enter イベントなどが発生しても、ボタンで予想外にコンテキストが変更されない)
- 「アクションを選択」で「フォームを送信」を選択する
- ［追加］をクリックする
［追加］ダイアログボックスで、サーバー上のデータを収集したり、電子メールの添付ファイルとしてフォームデータを収集したりするための URL を入力する

次の画像は、ボタンのプロパティダイアログボックスの［オプション］タブを示している。

レイアウトおよびラベルボタンのプロパティが表示されている、［ボタンのプロパティ］ダイアログボックスの［オプション］タブ

次の画像は、ボタンのプロパティダイアログボックスの「アクション」タブを示している。

事例 2: Adobe LiveCycle Designer ES 8.2.1 を使用して送信ボタンを追加する

挿入 > 標準メニューで、「HTTP 送信ボタン」項目を選択する
「HTTP 送信ボタン」の［オブジェクト］パネルに、フォーム送信処理の URL を挿入する

次の画像は、フォームコントロールの一覧が表示されている標準メニューを示している。

スクリーンショット:「HTTP 送信ボタン」が選択されている、フォームコントロールの一覧が表示されている標準メニュー

次の画像は、URL とボタンの外観に関するその他のフィールドが表示されたオブジェクトパネルを示している。

スクリーンショット: URL と送信ボタンの外観およびアクションを指定するためのその他のフィールドが表示されている［オブジェクト］パネル

事例 3: JavaScript を使用して PDF 文書内の送信ボタンにスクリプトアクションを追加する

次の JavaScript コードは、送信フォームアクションを指定するために使用されるスクリプトを示している。このスクリプトをフォームフィールドに追加するには、次の操作を行う。

事例 1 に示されているように、［ボタンのプロパティ］ダイアログボックスを開き、［アクション］タブを選択する
ドロップダウンリストから「JavaScript を実行」を選択し、「追加」ボタンを選択する
［JavaScript エディター］ダイアログボックスで、次のような JavaScript コードを入力する


var aSubmitFields = new Array( "name", "id", "juser" );
this.submitForm({
  cURL: "http://www.example.com/cgi-bin/myscript.cgi#FDF",
  aFields: aSubmitFields,
  cSubmitAs: "FDF" // デフォルト、ここでは不要
});

次の画像は、このプロセスを示している。

スクリーンショット: 送信ボタンの［ボタンのプロパティ］ダイアログボックス

スクリーンショット:［ボタンのプロパティ］ダイアログボックスの［アクション］タブに追加された JavaScript

この事例のサンプルとして、スクリプトアクションを送信ボタンに追加したサンプルがある。

参考リソース

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

Section 12.7.5.2 (Submit-Form Action) in PDF 1.7 (ISO 32000-1)
Create submission forms in LiveCycle Designer
XML Forms Architecture (XFA) Specification Version 2.5
PDF and Accessibility

検証

手順

フォームを送信するページごとに、送信ボタンが含まれているフォームを視覚的に確認し、以下のいずれかを確認する。
- ボタンにタブ移動し、ボタンを選択する利用者のアクションに反応してフォームが送信される。
- 送信フォームアクションを示すことができるツールを使用して PDF 文書を開き、ボタンアクションがフォームの送信であることを確認する。

期待される結果

フォームが含まれている各ページにおいて、1. の結果が真である。

PDF16: PDF 文書の文書カタログ内の /Lang エントリを使用して主たる言語を設定する

適用 (対象)

タグ付き PDF 文書

これは、次の達成基準に関連する達成方法である:

達成基準 3.1.1 (ページの言語)
- クイックリファレンス 3.1.1 (ページの言語)
- 達成基準 3.1.1 (ページの言語)を理解する

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

PDF16 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法の目的は、文書カタログ内の /Lang エントリを設定することにより、文書のデフォルト言語を指定することである。これは通常、PDF のオーサリングツールを使用して行う。

支援技術と従来のユーザエージェントはどちらも、文書の言語が指定されている場合に、より正確にテキストを表現できる。スクリーンリーダーは正しい発音規則をロードできる。視覚的なブラウザは文字やスクリプトを正しく表示できる。メディアプレイヤーはキャプションを正しく表示できる。このため、障害のある利用者にとってコンテンツが分かりやすくなる。

事例

事例 1: Adobe Acrobat 9 Pro を使用して、デフォルト文書言語を指定するために /Lang エントリを追加する

Adobe Acrobat Pro で文書を開く
［ファイル］メニューで［プロパティ］を選択する
［プロパティ］ダイアログボックスで、［アドバンスト］タブを選択する
「読み上げオプション」フィールドで「言語」コンボボックスからデフォルトの言語を選択する

スクリーンショット: Adobe Acrobat の［プロパティ］ダイアログボックスでデフォルト言語を指定

注記: Acrobat には 16 種類のプリセット言語が用意されている。一覧にない言語 (ロシア語など) を指定する必要がある場合は、言語の名前ではなくその言語の ISO 639 コードを入力する必要がある。

この事例のサンプルとして、Acrobat Pro を使用して /Lang エントリを追加したサンプル (PDF ファイル) がある。

事例 2: Microsoft Word 2007 を使用して PDF 文書内のデフォルト文書言語を指定する

Microsoft Word で作成された文書:「場合によっては、ソースファイルで文書の言語が指定されていても、その情報が PDFMaker に伝達されないことがある。文書のプロパティダイアログボックスで文書全体の言語を設定すると (事例 1 を参照のこと)、このオプションに関連するすべてのエラーが修正される」(Adobe® Acrobat® 9 Pro Accessibility Guide: Creating Accessible PDF from Microsoft® Word)

事例 3: /Lang エントリを使用して PDF 文書内のデフォルト文書言語を指定する

文書内のテキストに対して使用される自然言語は、オプションの /Lang エントリがいくつかの考えられる位置のいずれかに存在するかどうかに基づいて階層的に決定される。最高レベルで、文書のデフォルト言語は文書カタログ内の /Lang エントリにより指定できる。

次のコードフラグメントは、文書のデフォルト言語 (この場合、英語) の文書カタログ内で /Lang エントリを使用する一般的なコードを示している (これは通常、オーサリングツールを使用して行う)。


1 0 obj
   << /Type /Catalog
      ...
      /Lang (en-US)
      ...
   >> 
 endobj

参考リソース

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

Section 14.9.2 (Natural Language Specification) in PDF 1.7 (ISO 32000-1)
ISO 639-2 Codes
PDF Reference 1.6, 10.8.1 Natural Language Specification (PDF 8.7 Mb)
PDF Standards: Natural Language Specification
Adobe® Acrobat® 9 Pro Accessibility Guide: Creating Accessible PDF from Microsoft® Word
PDF and Accessibility

PDF19: PDF 文書内で Lang エントリを使用して節や句の言語を指定する

検証

手順

次のいずれかにより、文書のデフォルト言語が正しく指定されていることを確認する。
- PDF 文書をスクリーンリーダーで読み上げると、正しい自然言語でテキストが読み上げられる。
- PDF エディタを使用して、言語がデフォルト文書言語に設定されていることを確認する。
- 文書カタログ内の /Lang エントリ値を表示できるツールを使用して PDF 文書を開き、言語設定を表示する。
- アクセシビリティ API を通じて文書を表示するツールを使用して、言語がデフォルト言語に設定されていることを確認する。

期待される結果

1. の結果が真である。

PDF17: PDF 文書に一貫性のあるページ番号を指定する

適用 (対象)

タグ付き PDF 文書

これは、次の達成基準に関連する達成方法である:

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

PDF17 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法の目的は、PDF ビューアページコントロールに表示されるページ番号付けが文書のページ番号付けと同じであることを確認することにより、利用者が文書内の現在位置を確認できるよう支援することである。例えば、Adobe Acrobat Pro および Reader では、ページナビゲーションツールバーにページ番号が表示される。ページ番号の形式は、文書カタログ内の /PageLabels エントリにより指定される。

多くの文書では、文書内で特定のページ番号形式を使用する。一般に、前付けは小文字のローマ数字で番号付けされる。1 というページ番号で始まる主要コンテンツは、実際は文書の 5 ページ目または 6 ページ目である場合がある。同様に、付録はページ番号 1 で始まり、付録という英単語の接頭語が付けられる (例えば、「A-1」)。

コンテンツ制作者は、変換された文書のページ番号付けが、ユーザエージェントで表示されるページ番号に反映されていることを確認する必要がある。文書のページ番号表示の一貫性は、文書内の移動をより予測可能で分かりやすいものにするのに役立つ。

例えば、ページ番号付けの書式について記述する /PageLabels が提供されていない場合、ページ番号付けスキームが Adobe Acrobat Pro または Reader のページナビゲーションツールバーに反映されない。このツールバーでは、ページ番号がテキストボックスに表示される。利用者は、このテキストボックスのページ番号を変更して別のページに移動できる。さらに、利用者は、文書内で矢印を選択してページを上下に移動できる。ツールバーには相対的なページ番号の位置も表示される。以下の画像は、現在位置が 1/4 ページであることを示すデフォルトの表示を示している。

事例

事例 1: Adobe Acrobat 9 Pro を使用して PDF ページ番号の書式の指定を編集する

Microsoft Word 2007 から変換された事例の文書は 4 ページあり、i、ii、iii、1 という番号が付けられている。以下の画像は、Word で次のコマンドを使用して、小文字のローマ数字のページ番号付けが指定された Word 文書を示している。

［挿入］リボン > ページ番号 > ページ番号の書式設定

この文書では、アラビア数字の 1 で始まるページ番号付けを使用して、文書の 4 ページ目に新しいセクションが作成されている。その後、文書は Word から PDF に変換された。

スクリーンショット: 小文字のローマ字のページ番号付けが指定されている、Word のページ番号の書式設定ダイアログボックス

Adobe Acrobat Pro で、表示 > ナビゲーションパネル > ページを選択する。次の画像は、ページパネルおよびページナビゲーションツールバーのページサムネイルを示している。サムネイルとツールバーの両方で、アラビア数字のページ番号が使用されている。

スクリーンショット: ページパネルとページナビゲーションツールバーのページサムネイルの両方で、アラビア数字のページ番号が使用されている

ページ番号を修正するには、次の操作を行う。

番号を再設定するページを選択する
選択したページのコンテキストメニューから「ページ番号を設定」を選択する
ページ番号付けダイアログボックスで、小文字のローマ数字のスタイルと開始ページ (デフォルトでは 1、この場合はそのままで良い) を選択する
［OK］を押下する

次の画像は、ページ番号付けダイアログボックスと選択内容を示している。

スクリーンショット: 三つのページが選択されたページパネルと、新しいページスタイルが指定されたページ番号付けダイアログボックス開始ページは、正しい値である 1 (デフォルト) に指定されている。

同じプロセスに従い、4 ページ目のページ番号をアラビア数字の 1 に変更する。

以下の画像は、4 ページ目の正しいページ番号を示している。ページ iii がページパネルで選択されており、ページナビゲーションツールバーのテキスト領域に iii が表示されている。さらに、文書内の相対的位置 (3/4) がツールバーの右側に表示されている。

スクリーンショット: i、ii、iii、1 という番号が付いたページが示されている Adobe Acrobat Pro のページパネル。ページナビゲーションツールバーでは、3 ページ目に対して iii が表示されている。相対的なページ位置も「(3/4)」として表示されている

この事例のサンプルとして、Word から変換された文書内のページ番号を指定したサンプル (Word ファイル) と Word から変換された文書内のページ番号を指定したサンプル (PDF ファイル)がある。

より直接的にあるページへの移動を行うには、表示 > ナビゲーションパネル > ページメニュー項目へのショートカットを用いる方法がある。Windows においては、ショートカットは「Ctrl + Shift + N」、Mac OS では「Cmd + Shift + N」である。この方法により、特定のページ番号を入力するためのダイアログボックスが表示される。

事例 2: /PageLabels エントリを使用してページ番号を指定する

次のコードフラグメントは、文書内の複数のページ番号付けスキーマを指定する一般的なコードを示している。

以下の事例は、次のようなラベルがページに付けられる文書の例である。

事例: i, ii, iii, iv, 1, 2, 3, A-8, A-9, …

この番号付けスキームでは、三つのページラベル辞書 (小文字のローマ字、アラビア語、接頭語が付いた番号) が必要になる。

1 0 obj
    << /Type /Catalog
       /PageLabels << /Nums [ 0 << /S /r >>  % 小文字のローマ数字
                              4 << /S /D >>  % アラビア数字
                              7 << /S /D     % アラビア数字と...
                      /P (A-)                % 接頭語 "A-"...
                      /St 8                  % ページ 8 から開始
                                >>
                            ]
                    >>
       …
   >>
  endobj

ページラベルは次のように指定される。

/Sは、ページ番号の番号付けスタイルを指定する。
- /D - アラビア数字 (1、2、3...)
- /r - 小文字のローマ数字 (i、ii、iii...)
- /R - 大文字のローマ数字 (I、II、III...)
- /A - 大文字 (A ～ Z)
- /a - 小文字 (a ～ z)
/P (オプション) - ページ番号接頭語
/St (オプション) - 範囲内の最初のページ番号の値 (デフォルト: 1)

参考リソース

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

Section 12.4.2 (Page Labels) PDF 1.7 (ISO 32000-1)
PDF and Accessibility

PDF14: PDF 文書内に連続するヘッダーとフッターを提供する

検証

手順

異なるページネーション形式を使用する文書内の各セクションについて、文書のページで使用されている形式と同じものがページナビゲーション機能で使用されていることを確認する。
- 新しいページネーション形式を始めるページを選択すると、同じ形式およびページ番号がページネーション機能で表示される。
- スクリーンリーダーを使用して、ページナビゲーション機能で読み上げられるページ番号が、文書のページで読み上げられるページ番号と同じである。
- /PageLabels エントリを表示できるツールを使用して PDF 文書を開き、エントリを表示する。
- アクセシビリティ API を通じて文書を表示するツールを使用して、/PageLabels エントリが正しく指定されていることを確認する。

期待される結果

1. の結果が真である。

PDF18: PDF 文書の文書情報辞書内の Title エントリを使用して文書のタイトルを指定する

適用 (対象)

タグ付き PDF 文書

これは、次の達成基準に関連する達成方法である:

達成基準 2.4.2 (ページタイトル)
- クイックリファレンス 2.4.2 (ページタイトル)
- 達成基準 2.4.2 (ページタイトル)を理解する
注記: この達成方法は、達成基準 2.4.2 を満たす他の達成方法と組み合わせなければならない。詳細については、達成基準 2.4.2 を理解するを参照すること。

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

PDF18 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法の目的は、文書情報辞書内の /Title エントリを使用したり、ビューアの優先辞書内の DisplayDocTitle フラグを True に設定したりすることにより、PDF 文書の説明的なタイトルを支援技術用に指定できる方法を示すことである。これは通常、PDF のオーサリングツールを使用して行う。

文書のタイトルは、利用者がページの内容を読んだり解釈したりせずに現在位置を特定できるようにする。ユーザエージェントはページのタイトルを利用しやすくして、利用者がページを確認できるようにする。例えば、ユーザエージェントは、ウィンドウのタイトルバー内に、またはページを含むタブの名前としてページのタイトルを表示できる。

事例

事例 1: Adobe Acrobat 9 Pro を使用し、文書のタイトルをメタデータ内に設定して、タイトルがタイトルバー内に表示されるように指定する

Adobe Acrobat Pro で PDF 文書を開く。

ファイル > プロパティを選択する
［説明］タブを選択して、文書情報辞書を含む文書内のメタデータを表示する
「タイトル」フィールドを変更して、文書のタイトルエントリを追加または変更する

スクリーンショット: ［文書のプロパティ］ダイアログボックスの［説明］タブ内にある「タイトル」フィールド。文書のタイトルがフィールドに入力されている。

Adobe Acrobat がインストールされている場合、デスクトップからデータのプロパティを入力し、読み取ることもできる。ファイルのコンテキストメニューから［プロパティ］を選択し、［PDF］タブを選択する。このダイアログボックス内で入力または編集した情報も、ファイルを開いたときに［文書のプロパティ］の［説明］タブに表示される。

ユーザエージェントのタイトルバー内に文書のタイトルを表示するには、次の操作を行う。

ファイル > プロパティを選択する
［初期表示］タブを選択する
「ウィンドウオプション」セクションで、「表示」プルダウンリストの「文書のタイトル」を選択する

スクリーンショット: 文書のタイトルがタイトルバーに表示されるように指定する。「ウィンドウオプション」の「表示」で「文書のタイトル」が選択されている。

以下の画像に示されているように、タイトルがタイトルバーに表示される。

この事例のサンプルとして、文書のタイトルをタイトルバーに表示したサンプル (PDF ファイル) がある。

事例 2: PDF 文書の文書情報辞書内の /Title エントリ

次のコードフラグメントは、文書のタイトルを含む文書情報辞書内に /Title エントリを提供する一般的なコードを示している。


1 0 obj   
   << /Title (Applying Guerrilla Tactics to Usability Testing by People with Disabilities)    
      /Author (Mary Smith) 
      /CreationDate (D:19970915110347-08'00')    
   >>   
endobj

参考リソース

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

PDF and Accessibility
Section 14.3.3 (Document Information Dictionary) in PDF 1.7 (ISO 32000-1)
PDF Reference 1.6, TITLE entry of the document information dictionary

G88: ウェブページに説明的なタイトルを提供する

検証

手順

次のいずれかを適用することにより、文書のタイトルが正しく指定されていて、ユーザエージェントのタイトルバーに表示されることを確認する。
- PDF 文書をスクリーンリーダーで読み上げると、文書のタイトルが正しく読み上げられる。
- PDF エディターを使用して、文書のタイトルが指定されていること、また「初期表示」タブを選択し、タイトルが表示されることを確認する。
- 文書カタログ内の /Title エントリ値を表示できるツールを使用して PDF 文書を開き、/Title エントリおよび /DisplayDocTitle フラグ設定を表示する。

期待される結果

1. の結果が真である。

PDF19: PDF 文書内で Lang エントリを使用して節や句の言語を指定する

適用 (対象)

タグ付き PDF 文書

これは、次の達成基準に関連する達成方法である:

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

PDF19 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法の目的は、PDF 文書内の情報を提供するために /Lang エントリを使用して節、句または語の言語を指定することである。これによって、ユーザエージェントはテキストおよびその他の言語コンテンツを正しく提示できる。これは通常、PDF のオーサリングツールを使用して行う。

支援技術と従来のユーザエージェントはどちらも、言語が指定されている場合に、より正確にテキストを表現できる。スクリーンリーダーは正しい発音規則を用いることができる。それにより、障害のある利用者にとってコンテンツがより理解しやすくなる。

注記: 文書全体がコンテナまたはタグに含まれている場合は、この達成方法を使用して文書全体のデフォルト言語を設定できる。その場合、この達成方法は達成基準 3.1.1 に適用される。

事例

事例 1: Adobe Acrobat 9 Pro を使用して、段落の言語を指定するために /Lang エントリを追加する

ツールメニューの［高度な編集］を選択する
［TouchUp 読み上げ順序ツール］を選択する
TouchUp 読み上げ順序ツールの［順序パネルを表示］ボタンをクリックする
［順序パネルを表示］の［タグ］タブを選択し、異なる言語になっている段落を選択する。［タグ］タブの［オプション］メニューを使用して、［選択範囲からタグを検索］を選択することもできる/p>
選択範囲を右クリックして、コンテキストメニューから［プロパティ］を選択する
プロパティダイアログの［タグ］タブで、ドロップダウンリストから言語を選択する

事例 2: Adobe Acrobat 9 Pro を使用して、特定の語または句の言語を指定するために /Lang エントリを追加する

異なる言語になっている語または句を選択し、読み上げ順序パネルで対応するタグ (Text など) を作成する
［順序パネルを表示］の［タグ］タブを開き、異なる言語になっている、タグ付けされた語または句を選択する。［タグ］タブの［オプション］メニューを使用して、［選択範囲からタグを作成］を選択することもできる。
選択範囲を右クリックして、コンテキストメニューから［プロパティ］を選択する
プロパティダイアログの［タグ］タブで、ドロップダウンリストから言語を選択する

語または句にタグ付けすると、Acrobat は元のコンテンツを三つの文書コンテンツタグに分割する。つまり、選択範囲の前のテキストに対するタグ、選択範囲に対するタグ、および選択範囲の後のテキストに対するタグである。必要に応じて、選択したテキストの文書コンテンツタグを他の二つのタグの間にドラッグすると、そのテキストが正しい順序で読み上げられる。また、三つのタグはすべて親タグの下で同じレベルである必要がある。三つのタグが同じレベルでない場合は、ドラッグする。

スクリーンショット: TouchUp 読み上げ順序ツールの［順序パネルを表示］を使用して、テキスト内の語の言語を指定する

この事例のサンプルとして、Acrobat Pro を使用して特定の語または句をマークしたサンプル (PDF ファイル) がある。

事例 3: /Lang エントリを使用して PDF 文書内の語または句の言語を指定する

デフォルトの文書言語のレベル以下で、節の言語を次の項目に対して指定できる。

構造階層内にないマーク付きコンテンツ順序。Span タグが付いた、マーク付きコンテンツ順序に関連付けられたプロパティリストで /Lang エントリを使用。
任意の種類の構造エレメント。構造エレメント辞書で /Lang エントリを使用。

次のコードフラグメントは、/Lang エントリを使用して文書のデフォルト言語を変更する、一般的なコードを示している。デフォルト言語を変更するには、あるページのコンテンツストリーム内で、マーク付きコンテンツ順序を指定する。


/P % マーク付きコンテンツ順序の始まり
   BDC
      (See you later, or in Spanish you would say, ) Tj
      /Span << /Lang (es-MX) >>% ネストされたマーク付きコンテンツ順序の始まり
     BDC
      (Hasta la vista.) Tj
     EMC% ネストされたマーク付きコンテンツ順序の終わり
   EMC% マーク付きコンテンツ順序の終わり

次のコードフラグメントは、構造エレメント辞書内で /Lang エントリを使用する一般的なコードを示している。この場合、/Lang エントリは、表示されたページのコンテンツストリーム内の、MCID (マーク付きコンテンツの識別子) の値が 0 であるマーク付きコンテンツ順序に適用される。


1 0 obj% 構造エレメント
  << /Type /StructElem
    /S /Span% 構造タイプ
    /P /P% 構造階層の親
    /K<< /Type /MCR
      /Pg 2 0 R% マーク付きコンテンツのシーケンスを含むページ
      /MCID 0% マーク付きコンテンツの識別子
     >>
   /Lang (es-MX)% このエレメントに対する言語の指定
   >>
endobj
2 0 obj% ページオブジェクト
  << /Type /Page
     /Contents 3 0 R% コンテンツストリーム
   …
   >>
   endobj
3 0 obj% ページのコンテンツストリーム
  << /Length … >>
    stream
     BT
      /P % マーク付きコンテンツ順序の始まり
      BDC
     (See you later, or in Spanish you would say, ) Tj
     /Span << /MCID 0 >>% ネストされたマーク付きコンテンツ順序の始まり
    BDC
     (Hasta la vista.) Tj
    EMC% ネストされたマーク付きコンテンツ順序の終わり
  EMC% マーク付きコンテンツ順序の終わり
 ET
 endstream
 endobj

参考リソース

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

Section 14.9.2 (Natural Language Specification) in PDF 1.7 (ISO 32000-1)
ISO 639-2 Codes
PDF Reference 1.6, 10.8.1 Natural Language Specification (PDF 8.7 Mb)
PDF Standards: Natural Language Specification
Adobe® Acrobat® 9 Pro Accessibility Guide: Creating Accessible PDF from Microsoft® Word
PDF and Accessibility

PDF16: PDF 文書の文書カタログ内の /Lang エントリを使用して主たる言語を設定する

検証

手順

周囲のテキストの言語とは異なる節、句または語の言語が、タグによる囲みまたはコンテナ上の /Lang エントリによって正しく指定されていることを確認する。
- 句の言語および周囲のテキストの言語をサポートするスクリーンリーダーを使用して PDF 文書を読み上げ、テキストが正しい自然言語で読み上げられる。
- PDF エディターを使用して、異なる言語になっている語または句を選択し、言語が正しく設定されていることを確認する。
- /Lang エントリ値を表示できるツールを使用して PDF 文書を開き、言語設定を表示する。
- アクセシビリティ API を通じて文書を表示するツールを使用し、語または句の言語が正しく設定されていることを確認する。
コンテナまたはタグに文書全体が含まれている場合に、言語設定が、文書のデフォルトとして意図されている言語になっている。

期待される結果

1. 及び 2. の結果が真である。

PDF20: 間違ってタグ付けされているテーブルを修復するために、Adobe Acrobat Pro のテーブルエディタを使用する

適用 (対象)

テーブルが含まれているタグ付き PDF 文書

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

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

PDF20 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法の目的は、行と列の間の論理的な関係が維持され、支援技術により認識されるように、PDF 文書内のテーブルセルをマークアップする方法を示すことである。これは通常、PDF のオーサリングツールを使用して行う。

ただし、オーサリングツールで正しくマークアップされている場合でも、PDF に変換されたテーブルに、正しく結合または分割されないテーブルセルが存在する場合がある。コンテンツ制作者は、Adobe Acrobat Pro の TouchUp 読み上げ順序ツールのテーブルエディタを使用して、テーブルセルが適切に構造化されていることを確認できる。

事例

事例 1: Adobe Acrobat 9 Pro の TouchUp 読み上げ順序ツールのテーブルエディターを使用してテーブルセルを修復する

この事例では、Microsoft Word での作成時に正しくマークアップされていたテーブルを使用する。一部のテーブルヘッダーは、ヘッダー行が 2 行あり、テーブルヘッダーが 2 列に分かれている。

スクリーンショット：複雑なヘッダーのある、Word で正しくマークアップされたテーブル (PDF への変換前)

PDF 文書内のテーブルを確認するには、次の操作を行う。

アドバンスト > アクセシビリティ > TouchUp 読み上げ順序を選択する
テーブルの左上隅にある数字 (以下の画像の読み上げ順序 3) をクリックしてテーブルを選択する
TouchUp 読み上げ順序パネルで［テーブルエディタ］ボタンを選択する。テーブルセルに赤色のアウトラインが表示され、タグによってラベルが付けられる。赤いアウトラインはテーブルセルと厳密に一致するものではないが、それによってセルが正しくタグ付けされているかどうかを確認できる

次の画像は、TouchUp 読み上げ順序ツールのサンプルテーブルを示している。「Results」ヘッダーが二つのサブヘッダーにまたがって表示されており、左側にあるその他のヘッダーは「Results」ヘッダー内の二つの行にまたがっている。

スクリーンショット：TouchUp 読み上げ順序ツール内のテーブル。Word の場合と同様に、テーブルの「Results」ヘッダーは二つのサブヘッダーにまたがって表示されており、左側にあるその他のヘッダーは「Results」ヘッダー内の二つの行にまたがっている。

次の画像は、テーブルエディターでのサンプルテーブルを示している。セルには赤色のアウトラインが付けられ、各セルのタブが表示されている。変換時に、「Results」ヘッダーが正しく分割されず、二つのサブヘッダーにまたがっていない。右側にあるヘッダーは二つのセルに正しく分割されず、「Results」ヘッダーにまたがっていない。さらに、正しく分割されなかったセルが一つのセルに結合されている。

スクリーンショット：テーブルセルと各セルのタグを示している、テーブルエディターでのサンプルテーブル。テーブルエディターは、「Results」ヘッダーが正しく分割されず、二つのサブヘッダーにまたがっていないことを示している。その他のヘッダーも正しく分割および結合されていない。

「Results」ヘッダーを修復するには、次の操作を行う。

テーブル内でヘッダーを選択する (選択されると、青色のアウトラインが表示される)
コンテキストメニューにアクセスする
［テーブルセルのプロパティ］を選択する
［テーブルセルのプロパティ］ダイアログボックスで、「列のスパン」を「1」から「2」に変更する
［OK］を押す。変更により正しくないテーブル構造が生じた場合には、警告が表示される。この場合、変更は正しい。変更したセルは、次の画像に示されているように、新しい範囲を示すために色が変わる

スクリーンショット：この事例でタグ付けが間違っているヘッダーを修復するために「列のスパン」が「2」に変更された、［テーブルセルのプロパティ］ダイアログボックス

同様に、「Results」ヘッダーの左側にある正しく分割されていないヘッダーセルを修復するには、次の操作を行う。

列内で上部のセルを選択する (選択されると、青色のアウトラインが表示される)
コンテキストメニューにアクセスする
［テーブルセルのプロパティ］を選択する
［テーブルセルのプロパティ］ダイアログボックスで、「行のスパン」を「1」から「2」に変更する
［OK］を押す。次の画像は、左側にあるヘッダーセルが修正され、最後のヘッダーセルが修正された状態を示している

スクリーンショット：この事例でタグ付けが間違っているヘッダーを修復するために「行のスパン」が「2」に変更された、［テーブルセルのプロパティ］ダイアログボックス

次の画像は、修復されたサンプルテーブルを示している。

スクリーンショット：テーブルエディター内の修復されたサンプルテーブル。これで、元の Word の表と同じテーブル構造になっている。

この事例のサンプルとして、テーブル構造を修復するサンプル (Word ファイル) とテーブル構造を修復するサンプル (PDF ファイル)がある。

事例 2: テーブルの構造エレメントを使用してテーブルをマークアップする

次のコードフラグメントは、事例 1 ～ 3 に示すような単純なテーブル (ヘッダー行とデータ行) で一般的に使用されるコードを示している。


95 0 obj                % テーブルの構造エレメント
 << 
  /A 39 0 R
  /K[96 0 R 101 0 R 106 0 R 111 0 R]
  /P 93 0 R
  /S/Table              % 標準構造タイプはテーブル
 >> 
 endobj
96 0 obj                % テーブル行の構造エレメント
 << 
  /K[97 0 R 98 0 R 99 0 R 100 0 R]
  /P 95 0 R
  /S/TR                 % 標準構造タイプはテーブル行
 >> 
 endobj
97 0 obj                % テーブルヘッダーの構造エレメント
 <</A[23 0 R 120 0 R]
   /K 1
   /P 96 0 R
   /S/TH                 % 標準構造タイプはテーブルヘッダー
   /Pg 8 0 R
 >> 
endobj
104 0 obj                % テーブルデータの構造エレメント (セルのコンテンツ)
 << 
  /A 29 0 R
  /K 7
  /P 101 0 R
  /S/TD                  % 標準構造タイプはテーブルデータ
  /Pg 8 0 R
 >> 
endobj

参考リソース

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

PDF and Accessibility
14.8.4.3.4 (Table Elements) in PDF 1.7 (ISO 32000-1)

検証

手順

テーブルエディターで修復されたテーブルについて、次のいずれかの確認を行う。
- PDF 文書をスクリーンリーダーで読み上げると、テーブルヘッダーおよびデータセル間の論理的関係を維持する方法で表の情報が読み上げられる。 (表のヘッダーセルを読み上げるためにヒューリスティック手法が用いられないようにスクリーンリーダーを構成すること。)
- PDF エディターを使用し、適切な TR、TH および TD タグが正しい読み上げ順序でテーブルツリー内の階層に配置されていることを確認する。
- テーブルエレメントを表示できるツールを使用して PDF 文書を開き、テーブル構造を表示して、適切な TR、TH および TD 構造が含まれていることを確認する。
- アクセシビリティ API を通じて文書を表示するツールを使用して、テーブル構造に適切な TR、TH および TD 構造が含まれ、正しい読み上げ順序と階層になっていることを確認する。

期待される結果

1. の結果が真である。

PDF21: PDF 文書内のリストにリストタグを使用する

適用 (対象)

リストが含まれているタグ付き PDF 文書

これは、次の達成基準に関連する達成方法である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

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

PDF21 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法の目的は、リストエレメントを目的に応じて適切に使用して、関連項目のリストを作成することである。リストを含む PDF フォームは通常、PDF のオーサリングツールを使用して作成または修復される。

マークアップを使用して項目を視覚的にリストであるかのように書式設定したときに、リストの関係性が示されない場合は、情報間の移動が難しくなることがある。このような視覚的な書式設定の簡単な例としては、改行を使用したリスト項目の分割がある。

一部の支援技術では、利用者はリスト間または項目間を移動できる。リストがリストタグで正しく書式設定されていない場合、利用者はリストコンテンツを理解するのが難しくなる。

PDF コンテンツ内にリストを作成する最も簡単な方法は、オーサリングツール (Microsoft Word や OpenOffice.org Writer など) のリストマークアップを使用して正しく書式設定することである。ただし、ソースファイルやオーサリングツールを利用できない場合は、Adobe Acrobat Pro の TouchUp 読み上げ順序ツールおよびタグパネルを使用できる。

PDF 仕様は、節 14.8.4.3.3 (List Elements) でリスト構造を定義している (リストエレメント)。PDF 文書のリストの構造タイプを以下に示す。

L - リストタグ (一つ以上の LI タグを含む)
LI - リスト項目タグ。リスト項目タグには、Lbl タグと LBody タグを含めることができる
Lbl - リスト項目ラベル。項目番号や行頭文字などの識別情報を含む
LBody - リスト項目本体。リスト項目コンテンツを含む。ネストされたリストの場合には、追加のリストタグツリーを含むことがある

事例

事例 1: Microsoft Word 2007 文書にリストを追加する

［ホーム］リボンのリストツールを使用して、Word 文書内でリストを作成または修復する。PDF への変換時にリストが正しく書式設定されていることを確認するには、この方法が最も簡単である。

次の画像では、リストツールを使用して番号付きリストと箇条書きリストが作成されている。3 番目のリストにはリストツール (リボンを参照) を使用しなかったため、PDF への変換時にリストがリストエレメントとしてタグ付けされない。

スクリーンショット: Wordファイルで正しく書式設定された番号付きリストおよび記号付きリスト。3番目のセクションのテキストは、リストであるかのように表示されているが、Microsoft Word のリスト書式設定ツールは使用されていない。

事例 2: OpenOffice.org Writer 2.2 文書にリストを追加する

この事例は OpenOffice.org Writer の場合を示している。同様の機能を実行するソフトウェアツールは他にも存在する。他のソフトウェアツールのリストについては、「アクセシビリティがサポートされている PDF オーサリングツール」を参照のこと。

箇条書きと番号付けツールを使用して、OpenOffice.org Writer 文書内でリストを作成または修復する。PDF への変換時にリストが正しく書式設定されていることを確認するには、この方法が最も簡単である。

次の画像では、リストツールを使用して番号付きリストと箇条書きリストが作成されている。3 番目のリストにはリストツール (ツールバーを参照) を使用しなかったため、PDF への変換時にリストがリストエレメントとしてタグ付けされない。

スクリーンショット: OpenOffice.org Writerファイルで正しく書式設定された番号付きリストおよび記号付きリスト。3番目のセクションのテキストは、リストであるかのように表示されているが、OpenOffice.org Writer のリスト書式設定ツールは使用されていない。

この事例のサンプルとして、OpenOffice Writer 文書にリストを追加したサンプル (OpenDocument テキストファイル) がある。

事例 3: Adobe Acrobat 9 Pro を使用して、リストを正しく書式設定する

表示 > ナビゲーションパネル... > タグ
文書内のリストを検査して、書式設定に誤りがないかどうかを確認する。

次の画像では、3 番目のリストがテキストとして書式設定されている。このリスト項目は改行によってのみ分割されている。そのため、支援技術では、利用者に対してこれをリストとして分かりやすく表現できない。

リストを修復するには、［タグ］パネルを使用してコンテンツ内にリストタグを作成する。

次の画像は、結果として作成された、正しく書式設定された最初のリスト項目を示している。

この事例のサンプルとして、Acrobat Pro でリストが適切に書式設定されたサンプル (PDF ファイル) がある。

事例 4: List 構造エレメントを使用してリストをマークアップする

次のコードフラグメントは、PDF 文書内のリスト階層をマークアップする一般的なコードを示している。前述の事例では、単純な番号付けリストが使用されている。これは通常、オーサリングツールを使用して行う。

4 0 obj
  <</Type /Page
    /Contents 5 0 R
  >>

endobj
5 0 obj
  << /Length 3 0 R >>
  stream
   /P <</MCID 1>> BDC
      BT T* (The most popular sports are:) Tj ET EMC
   /Lbl <</MCID 11>> BDC
      BT T* (1. ) Tj ET EMC
   /LBody <</MCID 12>> /BDC
      BT (Snow-shoeing ) Tj ET EMC
   /Lbl <</MCID 21>> BDC
      BT T* (2. ) Tj ET EMC
   /LBody <</MCID 22>> /BDC
      BT (Ice-skating ) Tj ET EMC
   /Lbl <</MCID 31>> BDC
      BT T* (3. ) Tj ET EMC
   /LBody <</MCID 32>> /BDC
      BT (Skiing ) Tj ET EMC
endstream
endobj

101 0 obj                 % リストへの導入段落の構造エレメント ("The most popular sports are:")
  << /Type /StructElem
     /S /P
     /P 201 0 R
     /Pg 4 0 R
     /K 1
  >>
endobj

111 0 obj                  % 最初の項目の構造エレメント、リストラベル (Lbl): "1."
  << /Type /StructElem
     /S /Lbl
     /P 211 0 R
     /Pg 4 0 R
     /K 11
  >>
endobj

112 0 obj
  << /Type /StructElem     % 最初の項目の構造エレメント、リストテキスト (LBody): ("Snow-shoeing")
     /S /LBody
     /P 211 0 R
     /Pg 4 0 R
     /K 12
  >>
endobj

... [ objects 121-122 and 131-132, referencing MCIDs 21-22 and 31-32 are omitted in the interest of space. ]

201 0 obj
  << /Type /StructElem
     /S /Caption            % 導入段落
     /P 400 0 R
     /K [101 0 R]
  >>
endobj

211 0 obj
  << /Type /StructElem
     /S /LI                 % "1. Snow-shoeing" のリスト項目
     /P 400 0 R
     /K [111 0 R 112 0 R]
  >>
endobj

212 0 obj
  << /Type /StructElem
     /S /LI                 % "2. Ice-skating" のリスト項目
     /P 301 0 R
     /K [121 0 R 122 0 R]
  >>
endobj

213 0 obj
  << /Type /StructElem
     /S /LI                 % "3. Skiing" のリスト項目
     /P 301 0 R
     /K [131 0 R 132 0 R]
  >>
endobj

400 0 obj
  << /Type /StructElem
     /S /L                   % リスト階層内の最上位の構造エレメント
     /K [201 0 R 211 0 R 212 0 R 213 0 R]
  >>
endobj

参考リソース

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

Section 14.8.4.3.3 (List Elements) in PDF 1.7 (ISO 32000-1)
PDF and Accessibility

G115: 構造をマークアップするために、セマンティックな要素を使用する

検証

手順

PDF 文書内のリストについて、次のいずれかの方法で確認する。
- PDF 文書をスクリーンリーダーで読み上げ、コンテンツが 1 行単位で読み上げられるときにリストが正しく読み上げられる。
- リストを表示できるツールを使用して PDF 文書を開くと、リストを表示してリストが正しく構造化されている。
- タグツリーを検査すると、リストが PDF 仕様に基づいて構造化されている。
- アクセシビリティ API を通じて文書を表示するツールを使用して、リストが正しく構造化されていることを確認する。

期待される結果

1. が真である。

PDF22: PDF フォームにおいて、利用者の入力が必須形式又は値の範囲外となった場合に、そのことを明示する

適用 (対象)

タグ付き PDF 文書

これは、次の達成基準に関連する達成方法である:

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

PDF22 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

この達成方法の目的は、特定の必須形式 (日付フィールドなど) が求められるフィールドへの利用者の入力が、その形式で送信されないときに利用者に通知することを目的としている。

必須形式が使用されていない場合、エラーの性質について説明するテキストがアラートダイアログボックスで表示される。これは作成者が作成したスクリプトを通じて指定できる (例えば、「SCR18: クライアントサイドのバリデーション及びアラートを提供する」を参照のこと)。Adobe LiveCycle などのユーザエージェントでは、(以下の事例で説明されているように) 自動的にアラートを表示できる。

注記: 利用者がアラートダイアログボックスを閉じた後に、エラーの発生したフィールドにキーボードのフォーカスが移動するようにスクリプトを記述すると役立つ。ただし利用者によっては、アラートが表示される直前にフォーカスされていたコントロールにフォーカスが残ることを想定する場合がある。作成者は、利用者が想定するとおりにフォーカスを移動するよう注意を払う必要がある。例えば、電話番号の形式が間違っていることを示すアラートダイアログボックスが表示された場合に、アラートダイアログボックスを閉じると電話番号フィールドにフォーカスが置かれるようにすることは、利用者にとって役立ち、想定される動作であると考えられる。ただし場合によっては、これが不可能なことがある。ページ上で複数の入力エラーが発生した場合には、エラーを通知するための別のアプローチが取られる必要がある。

利用者が必ずエラーが発生したことに気付き、何が間違っているのかを判断し、修正できるようにすることは、ソフトウェアのユーザビリティとアクセシビリティにとって重要である。この目的を達成することは、すべての利用者が簡単かつ確実にフォームベースのトランザクションを完了できるようにするのに役立つ。

フォームコントロール内の必須形式のラベル

エラーが発生する可能性があることを利用者が認識することも重要である。この情報は、「日付 (MM/DD/YYYY)」のように、ラベルに組み込むことができる。「PDF10: PDF 文書内のインタラクティブなフォームコントロールにラベルを付ける」を参照のこと。

事例

事例 1: Adobe Acrobat 9 Pro を使用して入力フィールド形式の検証を提供する

電話番号、郵便番号、日付など、多くのフィールドでは、特定の形式またはパターンに従ってデータを入力する必要がある。

特定の形式を必要とするフォームコントロールのコンテキストメニューにアクセスする
［プロパティ］を選択する
［書式］タブで、「形式カテゴリ」(この場合は「日付」) を選択すると、「日付オプション」が表示される
このフォームコントロールの書式 (この場合、mm/dd/yyyy) を選択する
［一般］タブで、コントロールの名前およびツールチップとして「日付 (mm/dd/yyyy)」を指定する

スクリーンショット: Adobe Acrobat 9 Pro を使用して入力フィールド形式の必須形式を指定する

認識されている日付形式を利用者が入力すると、その日付形式は指定した形式に自動的に変換される。日付形式または値が認識されない場合、以下の画像に示されているように、エラーアラートが表示され、詳細情報が提示される。

スクリーンショット: 認識されない形式または値の日付に関するエラーアラート

この事例のサンプルとして、Acrobat の必須項目フィールドのサンプル (PDF ファイル) がある。

事例 2: Adobe LiveCycle Designer ES 8.2.1 を使用して入力フィールド形式の検証を提供する

必須形式のあるフォームコントロールを選択する
［オブジェクト］パレットで、［検証パターン］ボタンをクリックする
これは日付フィールドなので、パターン - 日付フィールドダイアログボックスが表示される。利用者が入力する必要のあるパターンまたは書式を選択する。［OK］をクリックする
［オブジェクト］パレットで、「検証パターンのメッセージ」ボックスを使用して警告メッセージを入力する。必要なパターンが含まれていることを確認する。このメッセージは、利用者が無効な日付書式を使用してフォームを発行しようとしたときに表示される

この事例のサンプルとして、LiveCycle Designer の必須フィールドのサンプル (PDF ファイル) がある。

事例 3: Adobe Acrobat Pro 9 を使用して、JavaScript を使用した PDF フォームで必須日付形式を検証する

次の JavaScript コードは、フォームフィールド (この場合は日付フィールド) を検証するために使用されるスクリプトを示している。このスクリプトをフォームフィールドに追加するには、事例 1 に示されているように、［テキストフィールドのプロパティ］ダイアログボックスを開き、［検証］タブの「編集」を選択する。

スクリーンショット: JavaScript 検証コードを指定するために［検証］タブが開かれている、［テキストフィールドのプロパティ］ダイアログボックス

// 日付マスク書式 MM/DD/YYYY 用の JavaScript コード
var re = /^[mdy0-9]{2}\/[mdy0-9]{2}\/[mdy0-9]{4}$/
//Allow blank space in field
if (event.value !="") {
  if (re.test(event.value) == false) {
    app.alert ({
       cTitle: "Incorrect Format",
       cMsg: "Please enter date using mm/dd/yyyy format"
    });
  }
}

参考リソース

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

JavaScript for Acrobat

検証

手順

特定の入力を必要とする各フォームフィールドについて、次の方法によって、検証情報と説明文が入力されていることを確認する。

求められる形式または値がフォームコントロールのラベルに示されていることを確認する。
誤りのある形式または値を使用し、フィールド以外の場所に移動する。エラーについて説明するアラートが表示されることを確認する。

期待される結果

1. 及び 2. が真である。

PDF23: PDF 文書内でインタラクティブなフォームコントロールを提供する

適用 (対象)

フォームが含まれているタグ付き PDF 文書
Adobe LiveCycle Designer で作成された PDF フォーム

これは、次の達成基準に関連する達成方法である:

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

PDF23 に関するユーザエージェントサポートノートを参照のこと。PDF テクノロジーノートも参照。

解説

このテクニックは、PDF 文書内のインタラクティブなフォームコントロールでキーボード操作を行えるようにすることを目的としている。インタラクティブな PDF フォームは通常、PDF のオーサリングツールを使用して作成される。フォームコントロールは、「PDF 1.7 (ISO 32000-1)」の節 12.7「インタラクティブフォーム」または「Adobe XML Forms Architecture (XFA)」のいずれかで説明されているように PDF 文書に実装される。

フォームコントロールを使用すると、利用者は、情報を入力したり選択肢を指定したりして PDF 文書を操作してから、送信して処理することができる。キーボードアクセスに依存している利用者は、視力のある利用者と同様に、フォームフィールドを認識して理解し、選択を行い、フォームに入力し、フォームを送信できなければならない。

インタラクティブなフォームコントロールは、スキャンした紙のフォームをタグ付き PDF に変換することにより作成されたフォーム、または Microsoft Word や Open Office などのオーサリングアプリケーションでフォームを作成し、タグ付き PDF に変換することにより作成されたフォームに対して提供できる。

ただし、フォーム設計機能を提供するオーサリングアプリケーションにより作成された文書は、PDF への変換時に、入力可能なフォームフィールドが完全には保持されない可能性がある。特に複雑なフォームでは、変換時にタグ付けされる際に、フォームフィールドおよびラベルが適切に変換されない場合がある。

Adobe Acrobat Pro を使用し、変換された文書内のフォームを用いて、次の操作を行うことにより、フォームフィールドがキーボードでアクセス可能で利用可能であることを確認できる。

フォームフィールドが含まれているタグ付き PDF 文書を開き、フォームフィールド認識の実行ツールを使用して、インタラクティブな PDF フォームエレメントを作成する
Adobe Acrobat Pro または Adobe LiveCycle Designer を使用して、入力可能なフォームフィールドを変更するか、フォームフィールドを追加する

Adobe LiveCycle Designer を使用して、フォームを最初から作成できる。

事例

事例 1: Adobe Acrobat 9 Pro を使用して、インタラクティブなフォームを PDF 文書内の既存のフォームに追加する

(紙のフォームをスキャンするか、オーサリングツールを使用してタグ付き PDF を生成することにより作成された) タグ付き PDF 文書内にフォームが含まれている場合、Adobe Acrobat Pro を使用して、静的なフォームと同じページ位置にあるフォームエレメントをキーボードでアクセス可能にすることができる。

アドバンスト > アクセシビリティ > フォームフィールド認識の実行を使用して、フォームフィールドを自動検出し、入力可能にする

次の画像は、タグ付き PDF に変換される文書内のフォームフィールドを検出するために、フォームフィールド認識の実行ツールが選択されている状態を示している。

スクリーンショット: Adobe Acrobat Pro の PDF 文書内のフォームフィールド。アドバンスト／アクセシビリティメニューが選択され、フォームフィールド認識の実行ツールが表示されている。

次の画像は、フォームフィールド認識の実行ツールの実行後に表示されるフォームフィールドを示している。

スクリーンショット: フォームフィールド認識ツールを実行した後の、Adobe Acrobat Pro の PDF 文書内のフォームフィールド

この事例のサンプルとして、Acrobat のインタラクティブなコントロールのサンプル (PDF ファイル) がある。

事例 2: Adobe Acrobat 9 Pro を使用してフォームコントロールを PDF 文書内に追加する

次のようにして、キーボードでアクセス可能なフォームコントロールをフォームに追加できる。

フォーム > フィールドを追加または編集を選択する。これにより、フォームがフォーム編集モードになる
左上にある新規フィールドを追加メニューを開き、追加するフォームフィールドを選択する。以下の画像はフィールドのメニューを示している

スクリーンショット: 使用可能なフォームフィールドの一覧が表示されている、新規フィールドを追加メニュー

次の画像は、事例 1 のフォームに追加されたチェックボックスを示している。

スクリーンショット: フィールドを追加または編集を使用してフォームに追加されたチェックボックス

この事例のサンプルとして、LiveCycle Designer のインタラクティブなコントロールのサンプル (PDF ファイル) がある。

事例 3: Adobe Acrobat 9 Pro を使用して PDF 文書内のフォームコントロールを編集する

フィールドを編集するには、フィールドのコンテキストメニューを選択し、［プロパティ］を選択する。［テキストフィールドのプロパティ］メニューでは、次の画像に示されているように、テキストフィールドを変更できる。

テキストフィールドを変更するための［テキストフィールドのプロパティ］ダイアログボックス

注記: ツールヒントはキーボードではアクセスできないが、スクリーンリーダーでアクセス可能である。PDF12: PDF 文書内のフォームフィールドの名前 (name)、役割 (role)、値 (value) 情報を提供するを参照のこと。

事例 4: Adobe LiveCycle Designer ES 8.2.1 を使用してインタラクティブなフォームを新規作成する

Adobe LiveCycle Designer を使用して、新規フォームを作成することができる。このスタンドアロンツールは、Windows のスタートメニューから起動できる他にも、Adobe Acrobat Pro 内で起動することができる。

フォーム > フォームウィザードの開始を選択する
次の画像に示されているように、「既存のフォームなし」ラジオボタンを選択する

スクリーンショット:「既存のフォームなし」ラジオボタンが選択されている、フォームウィザードの最初のダイアログボックス

「次へ」をクリックして LiveCycle Designer を起動し、次の画像に示されているように、新規フォームアシスタントの最初のページを開く。

スクリーンショット: LiveCycle Designer と新規フォームアシスタントの最初のページ

Windows スタートメニューから LiveCycle Designer を起動する場合、フォームウィザードはファイル > 新規作成から使用できる。

新規フォームアシスタントは空白のフォームを作成する。右側のウィンドウにあるオブジェクトライブラリを使用して、フォームコントロールを選択する。

LiveCycle Designer を使用して、一般的に使用されるフォームテンプレートに基づいてフォームを作成することもできる。

「新規」プルダウンからテンプレートアシスタントウィザードを起動する。
フォームを選択し、フォームの適切な種類を選択する。次に、プレースホルダテキスト、グラフィック、フォームフィールドおよびプロパティを、独自に提供または定義したカスタムオブジェクトに置き換えて、フォームをカスタマイズできる

スクリーンショット: LiveCycle Designer: フォームテンプレートのリスト

事例 5: /Tx フィールドの種類を使用して PDF 文書内にテキストフィールドを追加する

次のコードフラグメントは、事例 1 および 2 に示すような単純なテキストフィールドで一般的に使用されるコードを示している。このコードは通常、オーサリングツールにより実行される。


<< /AP -dict-                                                   
   /DA /Helv  0 Tf 0 g
   /DR -dict-
   /F 0x4
   /FT Tx              % テキストフィールドの Tx に設定された FT キー
   /P -dict-
   /Rect -array-
   /StructParent 0x1
   /Subtype Widget
   /T Date you are available   % 日付の部分的なフィールド名
   /TU Date you are available: use mm/dd/yyyy format % 簡単な説明として機能する TU ツールチップの値
   /Type Annot
   /V Pat Jones
>>
...
<Start Stream>
 BT
  /P <</MCID 0 >>BDC
  /CS0 cs 0  scn 
  /TT0 1 Tf
    -0.001 Tc 0.003 Tw 11.04 0 0 11.04 72 709.56 Tm
    [(P)-6(le)-3(as)10(e)-3( )11(P)-6(rin)2(t)-3( Y)8(o)-7(u)2(r N)4(a)11(m)-6(e)]TJ
  0 Tc 0 Tw 9.533 0 Td
  ( )Tj
  -0.004 Tc 0.004 Tw 0.217 0 Td
  [(\()-5(R)-4(e)5(q)-1(u)-1(i)-3(r)-3(e)-6(d)-1(\))]TJ
 EMC
  /P <</MCID 1 >>BDC
  0 Tc 0 Tw 4.283 0 Td
  [( )-2( )]TJ
   EMC
   /ArtifactSpan <</MCID 2 >>BDC
   0.002 Tc -0.002 Tw 0.456 0 Td
  [(__)11(___)11(___)11(___)11(___)11(_)11(____)11(___)11(___)11(__)]TJ
  0 Tc 0 Tw 13.391 0 Td
  ( )Tj
  EMC
 ET
<End Stream>

参考リソース

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

Section 12.7 (Interactive Forms) in PDF 1.7 (ISO 32000-1)
Adobe XML Forms Architecture (XFA)

検証

手順

各フォームコントロールについて、各フォームコントロールにタブ移動し、アクティブ化できることまたは値をキーボードから変更できることを確認することにより、適切に実装されていることを確認する。

期待される結果

1. が真である。

12. よくある失敗例

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

適用 (対象)

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

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

達成基準 1.3.2 (意味のある順序)
- クイックリファレンス 1.3.2 (意味のある順序)
- 達成基準 1.3.2 (意味のある順序)を理解する

解説

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

事例

失敗例 1

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

この例では、配置される各オブジェクトに対してクラスが定義されている。スタイルシートが適用されると、テキストは二つの段組みで表示される。まず、「menu1」クラスの要素 (Products) と「menu2」の要素 (Locations) は、カラムの見出しとして表示される。そして、「Telephones」「Computers」「Portable MP3 Players」は、Products の下に表示され、「Idaho」と「Wisconsin」は、Locations の下に表示される (Idaho と Wisconsin の順序は、ソースコードの順序とは異なっている)。

適切な構造要素が使われていないため、スタイルシートが適用されない状況では、全てのテキストがソースの順序に則って 1 列に提示され、「Products Locations Telephones Computers Portable MP3 Players Wisconsin Idaho」となってしまう。

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

コード例:


<div class="box">      
     <span class="menu1">Products</span>       
     <span class="menu2">Locations</span>       
     <span class="item1">Telephones</span>       
     <span class="item2">Computers</span>       
     <span class="item3">Portable MP3 Players</span>       
     <span class="item5">Wisconsin</span>       
     <span class="item4">Idaho</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 
}

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

参考リソース

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

C6: 構造を示すマークアップに基づいてコンテンツを配置する

検証

手順

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

文書からスタイル情報を取り除く、又はユーザエージェントでスタイルシートの使用を無効にする。
コンテンツの音声読み上げ順序が正しく、コンテンツの意味が変わっていないことを確認する。

期待される結果

手順 2. の結果が偽である場合、この失敗例の条件が適用され、コンテンツは達成基準の失敗となる。

F2: 達成基準 1.3.1 の失敗例－情報を伝えるために、適切なマークアップ又はテキストを用いずに、テキストの提示の変化を使用している

適用 (対象)

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

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

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

解説

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

事例

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

コンテンツ制作者は見出しを作成しようとしたが、デフォルトの HTML 見出しの見た目を望まなかった。よって見出しのように見えるように P 要素をスタイル付けするために CSS を使用し、これを見出しと呼んだ。しかし、適切な HTML 見出し要素を使用しそこなった。したがって、支援技術はそれを見出しとして見分けることができない。

コード例:


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

 <p class="heading1">Introduction</p>
 <p>This introduction provides detailed information about how to use this 
 ........
 </p>

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

失敗例 2: 見出しとして用いられる文字画像で、その画像が見出しタグでマークアップされていない

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

コード例:


<img src="Chapter1.gif" alt="Chapter One">
 
<p>Once upon a time in the land of the Web.....
</p>

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

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

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

コード例:


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

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


<p>
 "I said, <span class="yell">no</span>, not before dinner!", 
 was the exasperated response when Timmy asked his mother for the 
 fourth time for an ice cream cone. 
 </p>

参考リソース

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

検証

手順

文字画像の場合:
1. 全ての文字画像が、ドキュメントの構造情報を伝えるために使用されているかどうかを確認する。
2. 適切なセマンティック構造 (例: HTML の見出し) が情報を伝えるためにテキストとともに使用されていることを確認する。
(何らかの構造的な) 情報を表すために見た目が変更されているテキストの場合:
1. 構造的な情報を表現するために、見た目が変更されているテキストがある。
2. 見た目に加えて、適切なセマンティック構造によってテキストが表されていることを確認する。

期待される結果

1. の a. の結果が真である場合は、1. の b. の結果が真である。
2. の a. の結果が真である場合は、2. の b. の結果が真である。

F3: 達成基準 1.1.1 の失敗例－重要な情報を伝える画像を付加するために、CSS を使用している

適用 (対象)

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

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

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

解説

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">
  Where else would you find a better interest rate?
</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">Some book</li>
  <li class="instock">Some other book</li>
  <li class="limited">A book we desperately want to get rid of</li>
  ...
  <li class="outstock">A book you actually want </li>
</ul>

失敗例 3:

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

<p id="bestinterest" style="background: transparent url(/images/TopRate.png) no-repeat top left;" >
Where else would you find a better interest rate?
<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>

参考リソース

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

H37: img 要素の alt 属性を使用する

検証

手順

CSS HTML スタイル属性、又はスクリプトで動的に背景画像としてコンテンツに追加されている全ての画像を検査する。
画像が重要な情報を伝えていないことを確認する。
画像が重要な情報を伝えている場合、その情報は支援技術にも伝えられ、かつ CSS による画像が表示されない場合でも伝えられるようになっている。

期待される結果

手順 2 と手順 3 の結果が両方とも偽である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

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

適用 (対象)

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

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

達成基準 2.2.2 (一時停止、停止、非表示)
- クイックリファレンス 2.2.2 (一時停止、停止、非表示)
- 達成基準 2.2.2 (一時停止、停止、非表示)を理解する

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

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

解説

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

訳注: MDN の text-decoration に示されているとおり、モダンブラウザでは text-decoration: blink を設定したとしても、実際に点滅することはない。

事例

失敗例 1

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

コード例:


<p>My Great Product <span style="text-decoration:blink">Sale! $44,995!</span></p>

参考リソース

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

CSS 2 text-decoration property

訳注: 「text-decoration property」は、CSS Text Decoration Module Level 3§2.4. Text Decoration Shorthand: the text-decoration property で再定義されている。

SCR22: 点滅を制御し、5 秒以内に停止させるために、スクリプトを使用する

検証

手順

"blink" の値を持つ text-decoration プロパティがある、インラインでのスタイル指定、内部のスタイルシート、及び外部のスタイルシートを調べる。
プロパティを用いている場合、このプロパティが定義されているセレクタによって特定される ID、クラス又は要素がドキュメント内で用いられているかどうかを判断する。

期待される結果

手順 1. 及び手順 2. の結果が真である場合、コンテンツは達成基準の失敗となる。

F7: 達成基準 2.2.2 の失敗例－ 5 秒よりも長く点滅するコンテンツを一時停止するメカニズムなしでコンテンツを点滅している、Java 又は Flash などのオブジェクト又はアプレット

適用 (対象)

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

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

達成基準 2.2.2 (一時停止、停止、非表示)
- クイックリファレンス 2.2.2 (一時停止、停止、非表示)
- 達成基準 2.2.2 (一時停止、停止、非表示)を理解する

解説

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

訳注 1: NPAPI と呼ばれるプラグインは、ほとんどのブラウザでサポートが終息している。Java、Silverlight、Adobe Acrobat および他のプラグインが動作しなくなりました | Firefox ヘルプも参照されたい。

訳注 2: Oracle 社の Oracle Java SE サポート・ロードマップによれば、Java Plugin のサポートは 2019 年 3 月までと告知されている。

事例

ニュースのサイトでアプレットが広告を表示している。利用者の目を惹くために、アプレットは広告のキーワードを点滅させている。ユーザエージェントの設定によってその点滅を一時停止させることはできず、アプレットも点滅を停止させるメカニズムを提供していない。

SCR22: 点滅を制御し、5 秒以内に停止させるために、スクリプトを使用する

検証

手順

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

コンテンツが 5 秒よりも長く点滅するかどうかを測定する。
点滅しているコンテンツを一時停止させる手段があるかどうかを確認する。

期待される結果

1. の結果が真でありかつ、2. の結果が偽である場合、そのコンテンツは達成基準の失敗となる。

F8: 達成基準 1.2.2 の失敗例－一部の会話又は重要な効果音を省略しているキャプション

適用 (対象)

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

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

達成基準 1.2.2 (キャプション (収録済) )
- クイックリファレンス 1.2.2 (キャプション (収録済) )
- 達成基準 1.2.2 (キャプション (収録済) )を理解する

解説

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

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

事例

失敗例 1:

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

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

参考リソース

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

(今のところ、なし。)

検証

手順

キャプションを表示させてコンテンツを見る。
全ての発話内容がキャプションで示されていることを確認する。
全ての重要な音がキャプションに記述されていることを確認する。

期待される結果

2. 及び 3. の結果が偽である場合、この失敗例の条件は適用され、そのコンテンツは達成基準の失敗となる。

F9: 達成基準 3.2.5 の失敗例－利用者がフォーカスをフォーム要素から移動するときにコンテキストを変化させる

適用 (対象)

全般

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

達成基準 3.2.5 (要求による変化)
- クイックリファレンス 3.2.5 (要求による変化)
- 達成基準 3.2.5 (要求による変化)を理解する

解説

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

事例

失敗例 1:

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

参考リソース

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

検証

手順

フォーム要素を全て探す。
フォーム要素を順番に進んでいく。
あるフィールドから次のフィールドに移動するときにフォームが送信されるかどうかを確認する。
あるフィールドから次のフィールドへの移動が新しいウィンドウが開くかどうかを確認する。
あるフィールドから次のフィールドへの移動するときに別の画面に遷移するかどうかを確認する。

期待される結果

手順 3.、手順 4.、又は手順 5.の結果が真である場合、この失敗例の条件は適用され、そのコンテンツは達成基準の失敗となる。

F10: 達成基準 2.1.2 及び適合要件 5 の失敗例－利用者を一つのフォーマット型の中に閉じ込める方法で、複数のコンテンツフォーマットを組み合わせている

適用 (対象)

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

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

解説

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

事例

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

参考リソース

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

検証

手順

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

期待される結果

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

F12: 達成基準 2.2.5 の失敗例－利用者の入力を保存し、再認証時にその情報を再確立するためのメカニズムなしに、セッションの制限時間がある

適用 (対象)

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

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

達成基準 2.2.5 (再認証)
- クイックリファレンス 2.2.5 (再認証)
- 達成基準 2.2.5 (再認証)を理解する

解説

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

事例

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

G105: 利用者が再認証した後に利用できるようにデータを保存する

検証

手順

利用者の入力を収集していて、既知の非アクティブ時間の後に利用者のセッションを終了する、認証が必要なサイトにおいて:

必要な入力をした後、セッションをタイムアウトさせ、それからフォームを送信する。
要求された場合、サーバーで再認証する。
タイムアウト後に送信したデータが処理されるかどうかを確認する。

期待される結果

手順 3.の結果が偽である場合、サイトは達成基準の失敗となる。

F13: 達成基準 1.4.1 の失敗例－画像の色の違いで伝られる情報が含まれないテキストによる代替を持っている

適用 (対象)

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

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

解説

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

事例

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

参考リソース

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

G94: 非テキストコンテンツに対して、それと同じ目的を果たし、かつ同じ情報を示す、簡潔なテキストによる代替を提供する

検証

手順

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

色の違いによって伝えられている情報が、画像のテキストによる代替に含まれていないことを確認する。

期待される結果

手順 1. の結果が真である場合、この失敗例の条件は適用され、そのコンテンツは達成基準の失敗となる。

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

適用 (対象)

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

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

達成基準 1.3.3 (感覚的な特徴)
- クイックリファレンス 1.3.3 (感覚的な特徴)
- 達成基準 1.3.3 (感覚的な特徴)を理解する

解説

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

事例

サイトの操作説明に「次のページへ行くには、右のボタンを押してください。前のページに戻るには、左のボタンを押してください」と書いてある。
利用者がオンライン新聞サイトで新着記事を読んでいる。記事にはイラスト及びより多くの情報へのリンクがある。記事の文中には次のように書いてある。「この記事の続きへのリンクは、イラストの左側の関連記事欄にあります。」支援技術の利用者は、イラスト及び関連記事欄を見つけるのが困難である。考えられる解決策としては、記事の文中にリンクの一覧を含めること、記事文中に関連記事欄へのページ内リンクを提供すること、又は関連記事欄に何らかの見出しをつけて支援技術のナビゲーション機能が使えるようにして、説明文中でその見出しを示すことが挙げられる。
利用者がオンライン調査のフォームに入力している。調査フォームの最後に三つのボタンがある。説明文には「保存せずに入力を終えるには四角いボタン、入力内容を保存するには三角のボタンを押してください。後から入力を続けることができます。フォームを送信するには円いボタンを押してください。」と書かれている。スクリーンリーダーの利用者には、どのボタンが四角形、三角形又は円形なのかを知る術がない。ボタンには、それぞれの機能を示す情報 (ラベル) を付加しなければならない。

参考リソース

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

G96: 理解させる必要のあるアイテムを感覚的にだけ伝えるのではなく、テキストによる識別情報もあわせて提供する

検証

手順

ウェブページ内にあるコンテンツを示しているテキスト参照を調べる。
参照がコンテンツの視覚的な形又は位置だけに依存していないことを確認する。

期待される結果

2. の結果が偽である場合、この失敗基準が適用され、そのコンテンツは達成基準の失敗となる。

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

適用 (対象)

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

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

達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- クイックリファレンス 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- 達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )を理解する

解説

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

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

事例

失敗例 1

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

参考リソース

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

訳注: 「WAI-ARIA 1.0 Authoring Practices」は、正しくは「WAI-ARIA Authoring Practices 1.1」となる。

(今のところ、なし。)

検証

手順

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

期待される結果

手順 1. の結果が偽である場合、この失敗例の条件は適用され、そのコンテンツは達成基準の失敗となる。

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

適用 (対象)

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

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

達成基準 2.2.2 (一時停止、停止、非表示)
- クイックリファレンス 2.2.2 (一時停止、停止、非表示)
- 達成基準 2.2.2 (一時停止、停止、非表示)を理解する

解説

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

事例

ウェブページにスクロールするニュースティッカーがあり、そのスクロールを一時停止するメカニズムがない。なかには、スクロールするコンテンツを読むことができない利用者がいる。

G4: コンテンツを一時停止させて、一時停止させたところから再開できるようにする

検証

手順

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

ウェブページ又はユーザエージェントに、動きのあるコンテンツ又はスクロールするコンテンツを一時停止させるメカニズムが提供されていることを確認する。
一時停止させるメカニズムを用いて、動きのあるコンテンツ又はスクロールするコンテンツを一時停止させる。
動きのあるコンテンツ又はスクロールするコンテンツが停止し、そのまま再開しないことを確認する。
ウェブページ又はユーザエージェントに、一時停止したコンテンツを再開させるメカニズムが提供されていることを確認する。
再開させるメカニズムを用いて、コンテンツの動きを再開させる。
コンテンツの動き又はスクロールが、一時停止したところから再開されることを確認する。

期待される結果

手順 1.、手順 3.、手順 4.、又は手順 6.の結果が偽である場合、この失敗例の条件は適用され、そのコンテンツは達成基準の失敗となる。

F19: 適合要件 1 の失敗例－利用者に対して、不適合なウェブページの適合している代替版を見つける手段を提供していない

適用 (対象)

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

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

適合要件 1 (適合レベル)

解説

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

事例

リンク又は検索結果から、ウェブサイトにある適合していないウェブページへ利用者が直接誘導される。代替ページがあることを示すものがなく、又その適合していないウェブページから代替ページへのパスもない。
ウェブサイト上の不適合ページは、適合版が利用可能であり、かつホームページへのリンクを提供していることを利用者に知らせる。しかし、利用者はそのページのサイトの適合版のページを検索しなければならないため、この機能は達成基準の要件を満たさない。
利用者は、ほとんどのページで不適合なウェブサイトを使用できる。しかし、利用者が特定のページにアクセスできない場合、ページの適合版を見つける方法が存在しない。

G136: 不適合なウェブページの先頭に、適合している代替版を指すリンクを提供する

検証

手順

適合している代替版がある、適合していないウェブページを特定する。
適合していないウェブページが、適合している代替版へのリンクを提供しているかどうかを判断する。

期待される結果

手順 2. の結果が偽である場合、この失敗例の条件は適用され、そのコンテンツは達成基準の失敗となる。

F20: 達成基準 1.1.1 及び達成基準 4.1.2 の失敗例－非テキストコンテンツへの変更が発生するときにテキストによる代替を更新していない

適用 (対象)

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

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

解説

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

事例

失敗例 1: 10 月の成績に更新された売上表に対して、テキストによる代替が 9 月の成績の説明となっている。
失敗例 2: ホームページの絵を毎日変えているが、テキストによる代替が同時に更新されていない。
失敗例 3: スクリプトを使ってページ上の画像の source 属性を定期的に更新しているが、テキストによる代替が同時に更新されていない。

参考リソース

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

(今のところ、なし。)

検証

手順

テキストによる代替それぞれについて、現在表示されている非テキストコンテンツとは異なるコンテンツについて説明しているかどうかを確認する。

期待される結果

手順 1. の結果が真である場合、テキストによる代替は現在のアイテムに追随していないため、この失敗例の条件が適用され、そのコンテンツは達成基準の失敗となる。

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

適用 (対象)

全般

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

達成基準 3.2.5 (要求による変化)
- クイックリファレンス 3.2.5 (要求による変化)
- 達成基準 3.2.5 (要求による変化)を理解する

解説

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

事例

失敗例 1:

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

失敗例 2:

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

失敗例 3:

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

失敗例 4:

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

参考リソース

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

SCR24: 利用者の要求に応じて新しいウィンドウを開くために、プログレッシブエンハンスメントを使用する

検証

手順

ウェブページを表示させる。
新しい (追加の) ウィンドウが開くかどうかを確認する。
ウェブページ上のリンク及びボタンのような、アクションのある要素を探し出す。
各要素を操作する。
要素を操作すると新しいウィンドウが開く。
新しいウィンドウを開く要素にウィンドウを開くことを示す関連づけられたテキストがあるかどうかを確認する。そのテキストはリンクの中に表示されている、又は HTML の title 属性といった非表示の関連づけで利用できる。
訳注: title 属性に依存するような用法は、 HTML 仕様の The title attribute にも記載されているように、推奨されない。

期待される結果

手順 2. の結果が真である場合、この失敗例の条件は適用され、そのコンテンツは達成基準の失敗となる。
手順 5. の結果が真でありかつ手順 6. の結果が偽である場合、この失敗例の条件は適用され、そのコンテンツは達成基準の失敗となる。

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

適用 (対象)

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

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

達成基準 1.4.2 (音声の制御)
- クイックリファレンス 1.4.2 (音声の制御)
- 達成基準 1.4.2 (音声の制御)を理解する

解説

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

事例

失敗例 1

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

失敗例 2

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

参考リソース

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

(今のところ、なし。)

検証

手順

自動的に再生されて 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>Setting the canvas background</title>
    <style type="text/css">
       body {background-color:white}
    </style>
  </head>
  <body>
    <p>My background is white.</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>Setting the canvas background</title>
    <style type="text/css">
       body {color:white}
    </style>
  </head>
  <body>
    <p>My foreground is white.</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>A study of population dynamics</TITLE>
 <style type="text/css">
  a:link { color: red }
  a:visited { color: maroon }
  a:active { color: fuchsia }
 </style>
</head>
<body>
  <p>... document body... <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>A study of population dynamics</title>
          </head>
          <body bgcolor="white">
              <p> ... document body...</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>A study of population dynamics</title>
</head>
<body text="white">
  <p>... document body...</p>
</body>
</html>

参考リソース

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

Assigning property values, Cascading, and Inheritance

訳注: CSS2 の「Assigning property values, Cascading, and Inheritance」は、CSS Cascading and Inheritance Level 3 で再定義されている。この仕様は W3C 勧告ではないが、CSS Snapshot 2018 によれば、今日の CSS を構成する仕様として位置づけられている。

検証

手順

ウェブページのソースコードを調べる。
コンテンツ制作者が指定した前景色があるかどうかを確認する。
コンテンツ制作者が指定した背景色があるかどうかを確認する。

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

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

期待される結果

手順 2. の結果が真であるが手順 3. の結果が偽である、又は、手順 3. の結果が真であるが手順 2. の結果が偽である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

F25: 達成基準 2.4.2 の失敗例－コンテンツを特定しないウェブページのタイトル

適用 (対象)

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

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

達成基準 2.4.2 (ページタイトル)
- クイックリファレンス 2.4.2 (ページタイトル)
- 達成基準 2.4.2 (ページタイトル)を理解する

解説

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

事例

失敗例 1

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

オーサリングツールの初期設定のページタイトル。例えば、
- "ここに HTML ドキュメントのタイトルを入れてください"
- "無題ドキュメント"
- "タイトルなし"
- "無題ページ"
- "新しいページ 1"
それぞれの内容を示していないファイル名。例えば、"report.html" 又は "spk12.html" など。
空の (又は、意味のない) テキスト
埋め草又はプレースホルダーのテキスト

訳注: 埋め草とは、空いたところや、欠けた部分を埋め補うもののこと。フィラー。埋め草（うめくさ）の意味 - goo国語辞書も参照のこと。

失敗例 2

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

参考リソース

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

H25: title 要素を用いて、ページタイトルを提供する

検証

手順

各ウェブページのタイトルが、そのウェブページのコンテンツ又は目的を特定するかどうかを確認する。

期待される結果

1.の結果が偽である場合、この失敗例が適用され、そのコンテンツは達成基準の失敗となる。

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

適用 (対象)

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

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

達成基準 1.3.3 (感覚的な特徴)
- クイックリファレンス 1.3.3 (感覚的な特徴)
- 達成基準 1.3.3 (感覚的な特徴)を理解する

解説

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

事例

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

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

参考リソース

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

H37: img 要素の alt 属性を使用する

検証

手順

ページで情報を伝えている非テキストのマークを調べる。
非テキストのマークによって伝えている情報を把握できる他の手段があるかどうかを確認する。

期待される結果

2. の結果が偽である場合、この失敗基準が適用され、そのコンテンツは達成基準の失敗となる。

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

適用 (対象)

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

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

解説

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

事例

失敗例 1

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

画像や絵の「テキストによる代替」の位置に埋め込まれた、" "、"スペーサー"、"画像"、"絵" といったプレースホルダーテキスト。
非テキストコンテンツの情報又は機能を伝達しない、"絵 1"及び"絵 2" 、"0001"及び"0002" 又は"イントロ #1"及び"イントロ #2"といったプログラム上の参照情報
10 月.jpg、"グラフ.jpg" 又は "売上げ\\10 月\\上位 3 名.jpg"といったそれ自体では有効なテキストによる代替とならないファイル名

参考リソース

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

(今のところ、なし。)

検証

手順

テキストによる代替それぞれについて、実際にはその非テキストコンテンツに対するテキストによる代替ではないことを確認する。

期待される結果

手順 1. の結果が真である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

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

適用 (対象)

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

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

達成基準 3.2.4 (一貫した識別性)
- クイックリファレンス 3.2.4 (一貫した識別性)
- 達成基準 3.2.4 (一貫した識別性)を理解する

解説

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

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

事例

失敗例 1:

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

失敗例 2:

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

参考リソース

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

(今のところ、なし。)

検証

手順

ウェブページ一式の中で、複数のページで繰り返し使用されている同じ機能を持つコンポーネントを探す。
1.で見つけた同じ機能の個々のコンポーネントに対して、名称が一貫していることを確認する。

期待される結果

2.の結果が偽である場合、この失敗例が適用され、そのコンテンツは達成基準の失敗となる。

F32: 達成基準 1.3.2 の失敗例－単語内の間隔を制御するために、空白文字を使用している

適用 (対象)

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

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

達成基準 1.3.2 (意味のある順序)
- クイックリファレンス 1.3.2 (意味のある順序)
- 達成基準 1.3.2 (意味のある順序)を理解する

解説

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

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

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

事例

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

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

コード例:


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

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

コード例:


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

参考リソース

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

C8: 単語内の文字間隔を制御するために、CSS の letter-spacing を使用する

検証

手順

文字間に標準的でない空白があるように見える各単語について:

コンテンツのテキストを構成する単語が空白文字を含んでいるかどうかを確認する。

期待される結果

手順 1. の結果が真である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

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

適用 (対象)

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

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

解説

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

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

事例

失敗例 1

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

コード例:


Web Content Accessibility Guidelines      including blindness and low vision, 
2.0 (WCAG 2.0) covers a wide range of     deafness and hearing loss, learning 
issues and recommendations for making     difficulties, cognitive limitations, limited 
Web content more accessible. This         movement, speech difficulties, and 
document contains principles,             others. Following these guidelines will 
guidelines, Success Criteria, benefits,   also make your Web content more 
and examples that define and explain      accessible to the vast majority of users, 
the requirements for making Web-based     including older users. It will also enable
information and applications accessible.  people to access Web content using 
"Accessible" means usable to a wide       many different devices - including a 
range of people with disabilities,        wide variety of assistive technologies.

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

Web Content Accessibility Guidelines including blindness and low vision,
2.0 (WCAG 2.0) covers a wide range of deafness and hearing loss, learning
issues and recommendations for making difficulties, cognitive limitations, limited
Web content more accessible. This movement, speech difficulties, and
(以下省略)

一度削除したテキストを復活させたり、固定サイズのフォントが可変サイズに変更したり、何行かに及ぶテキストをそのページに収まらないくらい文字サイズを大きく変えたりした場合、同様の解釈の問題が視覚的提示で起こりうる。

参考リソース

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

(今のところ、なし。)

検証

手順

データ又は情報の文書が、多段組で示されている。
段組みが空白文字列を用いて情報を配置して作られているかどうかを確認する。

期待される結果

手順 2. の結果が真である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

F34: 達成基準 1.3.1 及び達成基準 1.3.2 の失敗例－プレーンテキストのコンテンツでテーブルの書式を整えるために、空白文字を使用している

適用 (対象)

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

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

解説

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

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

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

事例

失敗例 1

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

コード例:


Menu
         Breakfast        Lunch           Dinner
Monday   2 fried eggs    tomato soup     garden salad
         bacon           hamburger       Fried Chicken
         toast           onion rings     green beans
                         Oatmeal cookie  mashed potatoes
Tuesday   Pancakes       vegetable soup  Caesar salad
          sausage        hot dogs        Spaghetti with meatballs
          orange juice   potato salad    Italian bread
                         brownie         ice cream

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

Menu
Breakfast Lunch Dinner
Monday 2 fried eggs tomato soup garden salad
bacon hamburger Fried Chicken
toast onion rings green beans
Oatmeal cookie mashed potatoes

支援技術がテーブルとして特定するための構造がテーブルにないため、この読み上げ順序は意味をなさない。テキストがリフローする、又はは固定フォントから可変フォントに変更される、又は行がページに収まらなくなるまでサイズを大きくする場合、視覚的提示で同様の問題が発生する。

参考リソース

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

H51: 表形式の情報を提示するために、テーブルのマークアップを使用する

検証

手順

視覚的に整形されたテーブルのドキュメントを調べる。
テーブルのデータをレイアウトするために空白文字を使ってテーブルが作られているかどうかを確認する。

期待される結果

手順 2. の結果が真である場合、この失敗例の条件は適用され、コンテンツはこれらの達成基準の失敗となる。

F36: 達成基準 3.2.2 の失敗例－フォームの最後のフィールドに値を与えたときに、自動的にフォームを送信し、事前の予告なしに新しいコンテンツを提示している

適用 (対象)

HTML 及び XHTML

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

達成基準 3.2.2 (入力時)
- クイックリファレンス 3.2.2 (入力時)
- 達成基準 3.2.2 (入力時)を理解する

解説

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

事例

失敗例 1

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

参考リソース

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

検証

手順

ページ上のすべてのフィールドに、上から順にデータを入力する。
最後のフィールドにデータを入力して抜け出す (タブで抜ける)。
最後のフィールドから離れることで、コンテキストの変化が起こるかどうかを確認する。

期待される結果

手順 3 の結果が真である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

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

適用 (対象)

HTML 及び XHTML

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

達成基準 3.2.2 (入力時)
- クイックリファレンス 3.2.2 (入力時)
- 達成基準 3.2.2 (入力時)を理解する

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

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>Please select a mirror download site:</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>

参考リソース

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

(今のところ、なし。)

検証

手順

ページ中の各フォームを探す。
ラジオボタン、チェックボックス、又はセレクトリストの項目であるフォームコントロールそれぞれに、コントロールの選択を変更すると、新しいウィンドウが立ち上がるかどうかを確認する。
手順 2 に由来するそれぞれの新しいウィンドウごとに、事前に利用者に警告されているかどうかを確認する。

期待される結果

手順 3. の結果が偽である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

F38: 達成基準 1.1.1 の失敗例－支援技術が装飾的な画像を無視できる方法で、HTML でその画像をマークアップしていない

適用 (対象)

HTML 及び XHTML

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

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

解説

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

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

事例

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

参考リソース

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

(今のところ、なし。)

検証

手順

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

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

期待される結果

1. の結果が真であり、かつ 2. の結果が真である場合、この失敗条件が適用され、コンテンツは達成基準の失敗となる。

F39: 達成基準 1.1.1 の失敗例－支援技術によって無視されることが望ましい画像に対して、空ではないテキストによる代替を提供している (例: alt="spacer" 又は alt="image")

適用 (対象)

HTML 及び XHTML

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

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

解説

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

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

事例

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

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

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

参考リソース

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

検証

手順

装飾、スペーシング、又はページ内の意味のあるコンテンツの一部ではない他の目的に使用される img 要素を特定する
これらの要素に対する 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="en">
   <head>     
      <title>Do not use this!</title>     
      <meta http-equiv="refresh"
      content="5; url=http://www.example.com/newpage" />   
   </head>   
   <body>     
      <p>       
         If your browser supports Refresh, you'll be       
         transported to our        
         <a href="http://www.example.com/newpage">new site</a>        
         in 5 seconds, otherwise, select the link manually.     
      </p>   
   </body> 
</html>

参考リソース

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

HTML 4.01 META element

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記は、HTML 5.2§4.2.5. The meta element を代わりに参照できる。

検証

手順

ページを表示させる。
タイムアウトの後に、ページがリダイレクトされないことを確認する。

期待される結果

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="en">
  <head>     
    <title>HTML Techniques for WCAG 2.0</title>     
    <meta http-equiv="refresh" content="60" />   
  </head>   
  <body>
    ...     
  </body> 
</html>

(今のところ、なし。)

検証

手順

ドキュメント内の meta 要素を探す。
各 meta 要素について、http-equiv 属性の値に　"refresh" (大文字小文字を区別しない) が含まれており、かつ content 属性の数値 (秒を表す) が 0 以上で、"; url =" (大文字小文字を区別しない) を含まないかどうかを確認する。
リフレッシュを無効にするメカニズムがあるかどうかを確認する。

期待される結果

2. の結果が真であり、かつ 3. の結果が偽である場合、この失敗条件が適用され、コンテンツは達成基準の失敗となる。

F42: 達成基準 1.3.1、達成基準 2.1.1、達成基準 2.1.3、又は達成基準 4.1.2 の失敗例－リンクをエミュレートしている

適用 (対象)

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

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

解説

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

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

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

事例

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

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

コード例:


<span onclick="location.href='newpage.html'">
    Fake link
</span>

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

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

コード例:


   <img src="go.gif" 
   alt="go to the new page" 
   onclick="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="View Bargains"
		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">
View the results of the survey.
</div>

参考リソース

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

Accessible Rich Internet Applications (WAI-ARIA) Version 1.0

検証

手順

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

プログラムによる解釈のされた要素の役割 (role) が link かどうかを確認する。
エミュレートされたリンクが、キーボード操作で有効にできるかどうかを確認する。

期待される結果

1. の結果が偽である場合、この失敗条件が適用され、コンテンツは達成基準 1.3.1 及び 4.1.2 の失敗となる。2. の結果が偽である場合、この失敗条件が適用され、コンテンツは達成基準 2.1.1 及び 2.1.3 の失敗となる。

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

適用 (対象)

HTML 及び XHTML

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

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

解説

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

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

事例

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

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

コード例:


<p>Interested in learning more? Write to us at</p> 
<h4>3333 Third Avenue, Suite 300 · New York City</h4>

<p>And we'll send you the complete informational packet absolutely Free!</p>

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

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

コード例:


<h1>Study on the Use of Heading  Elements in Web Pages</h1>
<h3>Joe Jones and Mary Smith<h3>
<h4>March 14, 2006</h4>
<h2>Abstract</h2>
<p>A study was conducted in early 2006 ...
</p>

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

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

コード例:


<p>After extensive study of the company Web site, the task force 
identified the following common problem.</p>

<blockquote>
<p>The use of markup for presentational effects made Web 
pages confusing to screen reader users.</p>
</blockquote>

<p>The committee lists particular examples of the problems 
introduced by this practice below.</p>

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

コード例:


<fieldset>
<legend>Bargain Corner</legend>
<p>Buy today, and save 20%</p>
</fieldset>

参考リソース

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

検証

手順

要素のセマンティックな意味が支援技術に公開され、かつ要素のコンテンツに対して適切であることを確認する。

期待される結果

1. の結果が偽である場合、この失敗条件が適用される。

F44: 達成基準 2.4.3 の失敗例－意味及び操作性を保持しないタブ順序を作成するために、tabindex 属性を使用している

適用 (対象)

HTML 及び XHTML

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

達成基準 2.4.3 (フォーカス順序)
- クイックリファレンス 2.4.3 (フォーカス順序)
- 達成基準 2.4.3 (フォーカス順序)を理解する

解説

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

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

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

事例

失敗例 1

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

コード例:


<ol>
   <li><a href="main.html" tabindex="1">Homepage</a></li>
   <li><a href="chapter1.html" tabindex="4">Chapter 1</a></li>
   <li><a href="chapter2.html" tabindex="3">Chapter 2</a></li>
   <li><a href="chapter3.html" tabindex="2">Chapter 3</a></li>
</ol>

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

失敗例 2

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

参考リソース

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

HTML 4.01 Tabbing navigation

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。上記は、HTML 5.2§5.4.3. The tabindex attribute を代わりに参照できる。

H4: リンク、フォームコントロール、及びオブジェクトを通して、論理的なタブ順序を作成する

検証

手順

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

期待される結果

1. の結果が偽である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

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

適用 (対象)

HTML 及び XHTML

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

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

解説

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

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

headers 属性
scope 属性

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

WCAG 2 はレイアウトテーブルの使用を禁止していないが、HTML のテーブル関連要素の定義されたセマンティックな意味を保持し、コンテンツから提示を分離するコーディングの慣習に従うためにも、CSS ベースのレイアウトが推奨される。テーブルがレイアウトの目的で使用されるとき、th 要素を使用すべきではない。そのテーブルはデータを示していないため、どのセルも行又は列の見出しとしてマークアップする必要はない。同様に、コンテンツをレイアウトするためにのみ用いられているテーブルについて、追加の説明を提供する必要はない。summary 属性を含めない。そして、テーブルを「レイアウトテーブル」のような説明をするためにsummary 属性を使用しない。音声の場合、この情報は価値を提供せず、スクリーンリーダーを通してコンテンツをナビゲートする利用者の気を散らすだけである。空の summary 属性はレイアウトテーブルで許容されるが、推奨されない。

事例

失敗例 1

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

コード例:


 <table summary="layout table">
 <tr>
   <th colspan=3>Page Title</th>
 </tr>
 <tr>
   <td><div>navigation content</div></td>
   <td><div>main content</div></td>
   <td><div>right sidebar content</div></td>
 </tr>
 <tr>
   <td colspan=3>footer</td>
 </tr>
 </table>

参考リソース

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

検証

手順

HTML 又は XHTML のソースコードに、table 要素があることを確認する。
そのコンテンツ中で、視覚的レイアウトのみの目的でテーブルが用いられている場合
1. その table 要素には、th 要素が含まれていないことを確認する。
2. その table 要素が、値が空ではない summary 属性を含んでいないことを確認する。
3. その table 要素が caption 要素を含んでいないことを確認する。

期待される結果

上記の結果のいずれかが偽である場合、失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

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

適用 (対象)

HTML 及び XHTML

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

達成基準 2.2.2 (一時停止、停止、非表示)
- クイックリファレンス 2.2.2 (一時停止、停止、非表示)
- 達成基準 2.2.2 (一時停止、停止、非表示)を理解する

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

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

解説

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

訳注: HTML Standard の Non-conforming features に示されているとおり、blink 要素は廃止されている。モダンブラウザでは blink 要素を記述しても、実際に点滅することはない。参考リソースも参照されたい。

事例

失敗例 1

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

コード例:

<p>My Great Product <blink>Sale! $44,995!</blink></p>

参考リソース

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

検証

手順

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

期待される結果

1. の結果が真である場合、そのコンテンツは達成基準の失敗となる。

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

適用 (対象)

HTML 及び XHTML

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

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

解説

この文書は、表形式の情報をマークアップするために HTML の pre 要素を使用することによって引き起こされる失敗例について説明する。pre 要素は、視覚的なフォーマットだけを保持する。pre 要素を使用して表形式の情報をマークアップすると、利用者ユーザーが画面を見ることができない場合、又は視覚的提示が大きく変化した場合、表のセルとヘッダーとの間で視覚的に暗に示される論理的な関係性が失われる。

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

事例

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

コード例:


 <pre>
 	Monday	Tuesday	Wednesday	Thursday	Friday
 8:00-
 9:00	Meet with Sam				
 9:00-
 10:00			Dr. Williams	Sam again	Leave for San Antonio
 </pre>

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

コード例:


 <pre>
   CIRCUIT COURT JUDGE BRANCH 3
                                                  W
                                                   R
                                          M R E     I
                                           A . L     T
                                     M L    R   B     E
                                      I A    Y   E     -
                                       K N        R     I
                                        E G        T     N
                                       -----   -----   -----
0001 TOWN OF ALBION WDS 1-2               22      99       0
0002 TOWN OF BERRY WDS 1-2                52     178       0
0003 TOWN OF BLACK EARTH                  16      49       0
0004 TOWN OF BLOOMING GROVE WDS 1-3       44     125       0
0005 TOWN OF BLUE MOUNDS                  33     117       0
0006 TOWN OF BRISTOL WDS 1-3             139     639       1
0007 TOWN OF BURKE WDS 1-4                80     300       0
0008 TOWN OF CHRISTIANA WDS 1-2           22      50       0
 </pre>

参考リソース

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

H51: 表形式の情報を提示するために、テーブルのマークアップを使用する

検証

手順

pre 要素が使われているかどうかを確認する。
pre 要素が出現するたびに、囲まれた情報が表形式であるかどうかを確認する。

期待される結果

2. の結果が真である場合、この失敗基準が適用され、そのコンテンツは達成基準の失敗となる。

F49: 達成基準 1.3.2 の失敗例－線形化したときに、意味を成さない HTML のレイアウトテーブルを使用している

適用 (対象)

HTML 及び XHTML

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

達成基準 1.3.2 (意味のある順序)
- クイックリファレンス 1.3.2 (意味のある順序)
- 達成基準 1.3.2 (意味のある順序)を理解する

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

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

解説

WCAG 2 はレイアウトテーブルの使用を禁止していないが、HTML の table 要素の定義されたセマンティックな意味を保持し、コンテンツから提示を分離するコーディングの慣習に従うためにも、CSS ベースのレイアウトが推奨される。それにもかかわらずレイアウトテーブルを使用する場合、線形化したときにコンテンツが意味をなすことが重要である。

この失敗例は、コンテンツの視覚的配置を制御するために使用される HTML テーブルが正しく「線形化」されないことによって、提示を通じて伝えられる意味のあるコンテンツの順序が失われた場合に発生する。テーブルは、横及び縦の二つの視覚的な次元でコンテンツを提示する。しかし、スクリーンリーダーは、この 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

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

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

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

コード例:


<table>
<tr>
	<td><a href="#">Link 1</a></td>
	<td rowspan="20"><img src="img.png" alt="Museum Picture"></td>
	<td rowspan="6"><img src="placard.png" alt="Placard text"></td> 
</tr> 
<tr>
	<td><a href="#">Link 2</a></td>
</tr>
<tr>
	<td><a href="#">Link 3</a></td>
</tr>
<tr>
	<td><a href="#">Link 4</a></td>
</tr>
<tr>
	<td><a href="#">Link 5</a></td>
</tr>
<tr>
	<td><a href="#">Link 6</a></td>
</tr>
<tr>
	<td><a href="#">Link 7</a></td>
	<td rowspan="2"><h2>Image Heading</h2></td> 
</tr> 
<tr>
	<td><a href="#">Link 8</a></td>
</tr>
<tr>
	<td><a href="#">Link 9</a></td>
	<td rowspan="12">Description of the image</td> 
</tr> 
<tr>
	<td><a href="#">Link 10</a></td>
</tr>
 ...
<tr>
	<td><a href="#">Link 20</a></td>
</tr>
</table>

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

Link 1
Image
Placard Text
Link 2
Link 3
Link 4
Link 5
Link 6
Link 7
Image Heading
Link 8
Link 9
Link 10
...
Link 20

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

参考リソース

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

C6: 構造を示すマークアップに基づいてコンテンツを配置する

検証

手順

以下のいずれかの方法によってコンテンツを線形化する:
- コンテンツをソースコードの順序で表示する
- コンテンツを囲むテーブルのマークアップを除去する
線形化した読み上げ順序が、提示によって伝えられている意味のある順序と一致することを確認する。

期待される結果

2. の結果が偽である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

F50: 達成基準 2.2.2 の失敗例－ 5 秒以内に点滅を停止するメカニズムなしに、点滅効果を引き起こすスクリプト

適用 (対象)

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

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

達成基準 2.2.2 (一時停止、停止、非表示)
- クイックリファレンス 2.2.2 (一時停止、停止、非表示)
- 達成基準 2.2.2 (一時停止、停止、非表示)を理解する

解説

スクリプトを用いてコンテンツの表示、非表示を定期的に切り換えることで、コンテンツを点滅させることができる。スクリプトが 5 秒以内に点滅を止めるためのメカニズムを含まない場合は失敗例となる。点滅を停止させるための達成方法をどのように修正するかについての情報は SCR22: 点滅を制御し、5 秒以内に停止させるために、スクリプトを使用する (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">This content will blink</span>

SCR22: 点滅を制御し、5 秒以内に停止させるために、スクリプトを使用する

検証

手順

点滅しているそれぞれの箇所に対して:

点滅が 5 秒以内で止まるかどうかを確認する。

期待される結果

1. の結果が偽である場合、コンテンツは達成基準の失敗となる。

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

適用 (対象)

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

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

解説

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

事例

注記: この失敗例が引き起こされる可能性のある方法は複数存在する。さまざまなバージョンのユーザエージェントで別にサポートされている二つの一般的な事例が、例として以下に掲載されている。

失敗例 1:

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

訳注: HTML 4.01 は Superseded Recommendation としてマークされ、廃止された仕様である。

コード例:


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');
}

参考リソース

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

G107: コンテキストの変化に対するトリガーとして、"focus" ではなく、"activate" を使用する

検証

手順

新しいページをロードする
新しいページをロードしたことの結果として新しいウィンドウが開かれたかどうかを確認する
新しいウィンドウに自動的にフォーカスが移っているかどうかを確認する

期待される結果

手順 2．及び手順 3. の結果が真である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

F54: 達成基準 2.1.1 の失敗例－ある機能に (ジェスチャを含む) ポインティングデバイス特有のイベントハンドラのみを使用している

適用 (対象)

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

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

解説

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

事例

失敗例 1

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

参考リソース

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

SCR20: キーボードとその他のデバイス固有の機能を両方とも使用する

検証

手順

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

期待される結果

いずれかが見つかった場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

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();">Link Phrase</a>

参考リソース

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

(今のところ、なし。)

検証

手順

キーボードを使用して、すべてのインタラクティブな要素にキーボードでアクセスできることを確認する。
それぞれの要素がフォーカスされたとき、利用者がフォーカスを移動するまでフォーカスがそこに残っていることを確認する。

期待される結果

手順 2. の結果が偽である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

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

適用 (対象)

サーバーサイドのスクリプト言語全て
制限時間に関する達成基準の例外に当てはまらないコンテンツ

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

達成基準 2.2.1 (タイミング調整可能)
- クイックリファレンス 2.2.1 (タイミング調整可能)
- 達成基準 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>Redirect</title></head><body>");
	out.println("<p>This page will redirect you in 10 seconds.</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ソース-->

参考リソース

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

Hypertext Transfer Protocol -- HTTP/1.0 (IETF Request for Comments 1945) (plain text)
Hypertext Transfer Protocol -- HTTP/1.1 (IETF Request for Comments 2616) (plain text)

訳注 1: HTTP/1.0 は Informational な RFC であることに注意する。

訳注 2: 上記の HTTP/1.1 は RFC 2616 を参照しているが、現在の HTTP ステータスコードは RFC 7231 で更新・定義されている。

検証

手順

ウェブページがレンダリングされたとき、利用者が何もしなくても、一定時間後に自動的に他のページへリダイレクトするかどうかを確認する。

期待される結果

そのようなリダイレクトが見つかった場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

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

適用 (対象)

HTML 及び XHTML

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

達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- クイックリファレンス 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- 達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )を理解する

解説

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

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

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=""> Include Signature
  </span> 
  </p>

これは、マウスで 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 の失敗となる。

参考リソース

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

訳注: 「WAI-ARIA 1.0 Authoring Practices」は、正しくは「WAI-ARIA Authoring Practices 1.1」となる。

検証

手順

解析されたソースコードで、マークアップ内又はスクリプトを介して割り当てられたイベントハンドラを持つ要素 (ユーザインターフェースコントロールであることを示す要素) を検証する。
コントロールの役割 (role) がマークアップ言語でネイティブに定義されているかどうかを確認する。
適切な WAI-ARIA の役割 (role) の割り当てのように、他の有効なメソッドを使用してコントロールの役割 (role) を定義しているかどうかを確認する。

期待される結果

2. 及び 3. の結果が偽である場合、失敗条件が適用される。

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

適用 (対象)

全般

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

達成基準 3.2.5 (要求による変化)
- クイックリファレンス 3.2.5 (要求による変化)
- 達成基準 3.2.5 (要求による変化)を理解する

解説

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

事例

失敗例 1:

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

失敗例 2:

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

参考リソース

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

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

検証

手順

全てのテキストフィールドを探し出す。
各テキストフィールドの値を変更する。
新しいウィンドウが開くかどうかを確認する。
新しいウィンドウが開いている場合に、そのウィンドウにエラーメッセージがあり、ウィンドウを閉じて元のフォーム要素にフォーカスを戻すボタンがあることを確認する。

期待される結果

手順 3.の結果が真でありかつ、手順 4.の結果が偽である場合、この失敗例の条件は適用され、コンテンツはこの達成基準の失敗となる。

F61: 達成基準 3.2.5 の失敗例－利用者がコンテンツの中から無効にできない自動的な更新によってメインコンテンツの変更を完了する

適用 (対象)

全般

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

達成基準 3.2.5 (要求による変化)
- クイックリファレンス 3.2.5 (要求による変化)
- 達成基準 3.2.5 (要求による変化)を理解する

解説

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

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

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

事例

失敗例 1

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

失敗例 2

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

失敗例 3

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

参考リソース

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

(今のところ、なし。)

検証

手順

平均的な利用者がページに費やす時間を測定又は推定する。
ページに移動する
平均的な利用者がページに滞在する 10 倍の時間を待つ。(手順 1 から)
この間にコンテキストに変化があるかどうか確認する。
コンテキストの変化がない場合、終了する。
コンテキストの変化がある場合は、そのコンテキストの変化を止めるメカニズムがページに存在するかどうかを確認する。
コンテキストの変化を止めるメカニズムがある場合は、そのメカニズムを使用してコンテキストの変化を止めて、テストをやり直す。
コンテキストの変化があり、コンテキストの変化を止めるメカニズムがない場合は失敗となる。

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

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

期待される結果

手順 8 に達する場合、コンテンツはこの達成基準の失敗となる。

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

適用 (対象)

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

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

達成基準 2.4.4 (リンクの目的 (コンテキスト内) )
- クイックリファレンス 2.4.4 (リンクの目的 (コンテキスト内) )
- 達成基準 2.4.4 (リンクの目的 (コンテキスト内) )を理解する

解説

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

リンクとして同じ文章、段落、リストの項目、またはテーブルのセルの場合
前の見出しの場合
aria-label や aria-labelledby などの適切な ARIA プロパティを介する場合

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

事例

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

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


<p>A British businessman has racked up 2 million flyer miles and plans to 
travel on the world's first commercial tourism flights to space.</p>

<p><a href="ff.html">Read More...</a></p>

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

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


 <table>
   <tr> 
       <td>Play music from your browser</td>
   </tr>
   <tr>
       <td>
       <a href="http://www.example.com/download.htm">
       <img src="download.jpg" width="165" height="32" alt="Download now"></a>
       </td>
   </tr>
 </table>

参考リソース

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

訳注: 「WAI-ARIA 1.0 Authoring Practices」は、正しくは「WAI-ARIA Authoring Practices 1.1」となる。

検証

手順

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

コンテキストが同じ文章、段落、リスト項目、テーブルのセル、関連するテーブルのヘッダー、または前の見出しに含まれているかどうかを確認する。
例えば、リンク上で aria-label、aria-labelledby、aria-describedby などの WAI-ARIA プロパティを使用して、十分なコンテキストを提供するなど、リンクのコンテキストをプログラムによる解釈が可能かどうかを確認する。

期待される結果

1 及び 2 の結果が偽である場合、このコンテンツは達成基準の失敗となる。

F65: 達成基準 1.1.1 の失敗例－ `img` 要素、`area` 要素、及び `type "image"` の `input` 要素の `alt` 属性又はテキストによる代替を省略している

適用 (対象)

HTML 及び XHTML

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

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 1.1.1 (非テキストコンテンツ)を理解する

解説

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

いくつかの支援技術は、画像のファイル名を読み取ることにより、欠落しているテキストによる代替を補うことを試みる。しかし、多くの理由からファイル名に単純に頼るのは不十分である。例えば、ファイル名は説明的ではない場合があり (例 images/nav01.gif)、技術仕様には説明的なファイル名は必須ではない。そして多くの支援技術は HTML 属性を介して提供されるテキストによる代替がない場合はファイル名を読み取らない。

事例

失敗例 1: テキストによる代替が存在しない

以下のコード例において、スクリーンリーダーを使っている人は画像の目的を知ることはできない。

コード例:


    <img src="../images/animal.jpg" />

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

img、area 及び type "image" の input を特定する。これらの要素のそれぞれについて:

alt 属性が存在するかどうかを確認する。
aria-labelledby 属性が存在するかどうかを確認し、かつページ内の一つ以上の id 要素を参照し、かつ aria-labelledby がアクセシビリティサポーテッドかどうかを確認する。
aria-label 属性が存在するかどうかを確認し、かつ aria-label がアクセシビリティサポーテッドかどうかを確認する。
title 属性が存在するかどうかを確認し、かつ title がアクセシビリティサポーテッドかどうかを確認する。

期待される結果

1.、2.、3.、及び 4. の全ての結果が偽である場合、この失敗条件が適用される。

F66: 達成基準 3.2.3 の失敗例－異なるページでさまざまな相対的な順序でナビゲーションリンクを提示している

適用 (対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

達成基準 3.2.3 (一貫したナビゲーション)
- クイックリファレンス 3.2.3 (一貫したナビゲーション)
- 達成基準 3.2.3 (一貫したナビゲーション)を理解する

解説

この文書では、ウェブページ一式の中にある複数のウェブページ上で繰り返されているナビゲーションメカニズム (達成基準 3.2.3) を含むすべての達成方法における失敗例の条件を説明している。メカニズムが、2 ページ以上に異なる順序でリンクの順番を提示する場合、失敗例は起こる。

事例

失敗例 1: 二つの異なるページで相対的に異なる順序で一連のリンクを提示している XHTML メニュー

異なる順序でリンクを提示するナビゲーションメカニズムの例。

1 ページ目のメニュー

コード例:


<div id="menu"> 
    <a href="Brazil.htm">Brazil</a><br />
    <a href="Canada.htm">Canada</a><br />
    <a href="Germany.htm">Germany</a><br />
    <a href="Poland.htm">Poland</a> 
</div>

2 ページ目のメニュー

コード例:


<div id="menu"> 
    <a href="Canada.htm">Canada</a><br />
    <a href="Brazil.htm">Brazil</a><br />
    <a href="Germany.htm">Germany</a><br />
    <a href="Poland.htm">Poland</a> 
</div>

参考リソース

この達成方法に関する参考リソースはない。

(今のところ、なし。)

検証

手順

ナビゲーションメカニズムが複数のウェブページ上で使用されている。
各ページのナビゲーションメカニズムのデフォルトの提示を確認し、リンクリストが各ウェブページ上で相対的に同一の順番になっているかどうかを確認する。

注記: 「相対的に同一の順番」は、あるページではリンク項目間に補助的なナビゲーション項目があるかもしれないことを意味する。これらが存在しても、この検証の結果に影響を及ぼすことはない。

期待される結果

1．の結果が真でありかつ 2．の結果が偽である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

F67: 達成基準 1.1.1 及び達成基準 1.2.1 の失敗例－非テキストコンテンツに対して、同じ目的を果たしていない、又は同じ情報を提示していない長い説明を提供している

適用 (対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この文書は、非テキストコンテンツに対する長い説明が非テキストコンテンツと同じ目的を果たしていない、又は非テキストコンテンツと同じ情報を提供していないことによる失敗例について述べている。このことは非テキストコンテンツを読み取ることができない利用者にとって問題となる。なぜならば、これらの利用者は、非テキストコンテンツが伝達する必要な情報を長い説明から得ているためである。完全な情報を提供する長い説明がないと、ウェブページを理解したり、操作したりすることができない。

事例

街路図にオリンピック種目の開催地が表示されている画像がある。画像には各開催地で催される競技種目のアイコンがある。長い説明には「地図には、オリンピック種目の開催地が表示されています。スケート、ホッケー、及びカーリングはウィンター公園アイスアリーナで開催され、滑降とジャンプはスノーマウンテン、体操はジャンプアップアリーナ、クロスカントリースキーはキロメーターフォレストです。」と書かれている。この説明は有益な情報を提供しているが、画像と同じ情報を伝達していない。なぜならば、説明には、住所又はいくつかの地点からの会場までの距離といった具体的な会場の位置情報が提供されていないからである。長い説明は常に文章形式である必要はないことに留意する。情報はテーブルや他の形式で提供されるほうが最もよい場合がある。

参考リソース

この達成方法に関する参考リソースはない。

検証

手順

長い説明が必要な全ての非テキストコンテンツに対して:

長い説明が非テキストコンテンツと同じ目的を果たす、又は同じ情報を提供していることを確認する。

期待される結果

手順 1.の結果が偽である場合、この失敗例の条件は適用され、コンテンツはこの達成基準の失敗となる。

F68: 達成基準 4.1.2 の失敗例－プログラムによる解釈が可能な名前 (name) を持っていないユーザインタフェースコントロール

適用 (対象)

HTML のコントロール

これは、次の達成基準に関連する失敗例である:

達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- クイックリファレンス 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- 達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )を理解する

解説

この失敗例は、フォームコントロールの名前が支援技術に公開されていない場合に発生する問題を説明する。その結果、一部の利用者はフォームコントロールの目的を特定できなくなる。名前 (name) は、label 要素を含む複数の方法で指定できる。他のオプションには、アクセシビリティ名に使用されるテキストを直接提供するために使用される title 属性および aria-label の使用、又はその名前 (name) を提供しているページ上の他のテキストとの関連を示す aria-labelledby が含まれる。ボタンコントロールには、以下に示すように、別の方法で名前 (name) を割り当てることができるが、特定の状況では label、title、aria-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>
 First name: 
 <input type="text" name="firstname">
 <br>
 Last name: 
 <input type="text" name="lastname">
 <br>
 I have a dog <input type="checkbox" name="pet" value="dog">
 I have a cat <input type="checkbox" name="pet" value="cat">
</form>

失敗例 2:

次のコード例では、 label 要素は存在するが、対応するインプットコントロールとプログラム的に関連付けられていないため、支援技術によって正しく判定されない可能性がある。


<form action="..." method="post"> 
<p> 
<label>First Name</label>
<input type="text" name="firstname"> 
<label>Last Name</label> 
<input type="text" name="lastname"> 
</p> 
</form>

失敗例 3:

次のコード例の検索テキストボックスには、プログラムによる解釈が可能な名前がない。名前 (name) は、上記の方法のいずれかで提供することができる。


<input type="text" value="Type your search here"><input type="submit" type="submit" value="Search">

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

WAI-ARIA Accessible Name Calulation

検証

手順

ウェブページ内のすべての input、textarea 及び select 要素 ("hidden"、"submit"、"reset"、又は "button" の input を除く):

次のいずれかの方法で、各要素にプログラムによる解釈が可能な名前が付いていることを確認する。
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

これは、次の達成基準に関連する失敗例である:

達成基準 1.4.4 (テキストのサイズ変更)
- クイックリファレンス 1.4.4 (テキストのサイズ変更)
- 達成基準 1.4.4 (テキストのサイズ変更)を理解する

解説

この文書は、テキストのサイズ変更によって、テキストが切り取られたり、端が欠けたり、又は覆い隠されたりして、利用者がテキストを入手できなくなるという失敗例について述べている。一般的に、この失敗例は、ユーザエージェントのレイアウトエンジンが、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 のイラストによる説明:

(今のところ、なし。)

検証

手順

コンテンツのテキストの文字サイズを 200 ％拡大する。
テキストが切り取られたり、端が欠けたり、又は覆い隠されたりしていない。

期待される結果

手順 2. の結果が偽である場合、失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

F70: 達成基準 4.1.1 の失敗例－開始タグ及び終了タグ、又は属性のマークアップを誤って使用している

適用 (対象)

マークアップ言語: HTML、XHTML、及び他の SGML 又は XML ベースのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

達成基準 4.1.1 (構文解析)
- クイックリファレンス 4.1.1 (構文解析)
- 達成基準 4.1.1 (構文解析)を理解する

解説

この失敗例の目的は、要素タグにおいて、支援技術が満足できるページのモデルを生成できない原因となるマークアップの誤りの例を特定することである。ユーザエージェントは、エラーから復旧するために、異なる推測に基づいた方法をそれぞれ実装している。結果として、ユーザエージェント間で一貫性のないページのプレゼンテーションとなっている。

(これは完全なリストではないが) この失敗例の条件を生じさせる開始及び終了タグの一般的な問題:

開始の < 及び終了の > の括弧が足りない開始及び終了タグ。
終了タグであることを示す最初の / が足りない終了タグ。
開始の引用符はあるが、終了の引用符がない属性値。属性値は、引用符で完全にくくられているか、又はあるマークアップ言語では、引用符でくくられていないかのどちらかである。
属性間の空白の欠如。
値に空白のある引用符でくくられていない属性値。
空の要素の構文が使用できない要素のための終了の要素タグを提供しない場合。

事例

失敗例 1: XHTML の山形括弧が足りない

開始タグに山形括弧がなく、タグの意図する境界が不明瞭であるため、下記のコードは失敗となる。

コード例:


<p This is a paragraph</p>

失敗例 2: XHTML の終了タグのスラッシュが足りない

終了タグにスラッシュがなく、事実上、別の開始タグのように見えるため、下記のコードは失敗となる。

コード例:


<p>This is a paragraph<p>

失敗例 3: 均衡が取れていない属性の引用符づけ

属性値に終了の引用符がないことで、属性値の対の境界が不明確となるため、下記のコードは失敗となる。

コード例:


<input title="name type="text">

失敗例 4: 属性間の空白の欠如

属性間に空白がないことで、属性値の対の境界が不明確となるため、下記のコードは失敗となる。

コード例:


<input title="name"type="text">

失敗例 5: 空白スペースを含む値を持つ引用符がついていない属性

属性値に引用符がつけられておらず、値に空白が含まれていることで、属性値の対の境界が不明確となるため、下記のコードは失敗となる。

コード例:


<input title=Enter name here type=text>

失敗例 6: XHTML の終了タグが足りない

第 1 パラグラフの終了タグがないことで、第 2 パラグラフが第 1 パラグラフの子なのか兄弟なのかが不明確になるため、下記のコードは失敗となる。

コード例:


<p>This is a paragraph
<p>This is another paragraph</p>

(今のところ、なし。)

検証

手順

ページのソースコードがマークアップ言語で実装されていることを確認する。
開始タグ、終了タグ又は属性で不正な形式になっているものがあるかどうかを確認する。

期待される結果

手順 2.の結果が真である場合、この失敗例の条件は適用され、コンテンツは達成基準を満たしていない。

F71: 達成基準 1.1.1 の失敗例－テキストを表すために、テキストによる代替を提供せずに、テキストのようなものを使用している

適用 (対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 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」という単語のように見える。この場合、これらの文字が、文字実体で実装されているが、やはり単語として意味のあるかたちでは処理されず、テキストによる代替は提供されていない。

コード例:


      &#x03F2;&#x043E;&#x03BF;&#x006B;

コード例の実際の表示例: "ϲоοk"

(今のところ、なし。)

検証

手順

テキストを表現するために、文字又は文字実体を用いていることを確認する。
用いられている文字は、コンテンツの自然言語において表示されるグリフの適切な文字と一致しない場合、見た目が似たグリフが使われている。

期待される結果

よく似たグリフが使用され、かつよく似たグリフを使用するテキストの範囲に対してテキストによる代替がない場合、コンテンツは達成基準を満たしていない。

F72: 達成基準 1.1.1 の失敗例－テキストによる代替を提供せずに、ASCII アートを用いている

適用 (対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

達成基準 1.1.1 (非テキストコンテンツ)
- クイックリファレンス 1.1.1 (非テキストコンテンツ)
- 達成基準 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
     Flash frequency (Hz)
</pre>

(今のところ、なし。)

検証

手順

ASCII アートのあるページを開く。
それぞれの ASCII アートに対して、テキストによる代替が提供されていることを確認する。

期待される結果

2. の結果が偽である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

F73: 達成基準 1.4.1 の失敗例－色覚なしで視覚的にはっきりと分からないリンクを作成する

適用 (対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

達成基準 1.4.1 (色の使用)
- クイックリファレンス 1.4.1 (色の使用)
- 達成基準 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>To find out more about the <a href="rain_in_spain.htm">rain in spain</a>there are many resources.</p>

</body>

注記: 視覚的な手掛かりが、(上の例のように) マウスオーバーした際のみ提供される場合、それはやはり失敗となる。

検証

手順

色 (色相) で識別可能なページ内の各リンクが、他の手段 (例えば、下線、太字、イタリック、明度の差など) によって視覚的に識別可能であることを確認する。

期待される結果

1. の結果が偽である場合、この失敗例の条件は適用され、コンテンツはこの達成基準の失敗となる。

F74: 達成基準 1.2.2 及び達成基準 1.2.8 の失敗例－テキストに対する同期したメディアによる代替を、代替としてラベル付けしていない

適用 (対象)

テキストに対する代替である同期したメディアを提供しているウェブページ

これは、次の達成基準に関連する失敗例である:

解説

この失敗例の目的は、テキストの代替メディアとなる同期したメディアに対して、そのテキストを含んだラベルが付けられていないという状況を回避することである。テキストの代替メディアとなる同期したメディアは、同期したメディアの方がテキストよりも有効なフォーマットとなる利用者に対して、情報へのより良いアクセスを提供する。同期したメディアがテキストの代替であるため、それ自体に冗長なテキストによる代替を必要としない。しかし、その同期したメディアに対して、テキストの代替メディアであることを明確にラベル付けすることによって、利用者がテキストの代替メディアである同期したメディアを見つけられるようにし、また同期したメディアに対して通常はそのテキストによる代替を期待する利用者が、テキストによる代替を探さないようにする必要がある。

事例

失敗例 1: 同期したメディアの代替がページ上の他のどこかで提供されている

納税申告書の記入方法を説明したウェブページで、記入すべき項目や提供すべきデータなどの説明が文章で書かれている。さらに、テキストの代替メディアとなる同期したメディアが、音声による説明を提供しており、その音声で説明されている部分を記入している人の映像がある。文章のバージョンと同期したメディアのバージョンの両方がウェブページで提供されているにもかかわらず、同期したメディアのバージョンはそのウェブページの他の場所にあり、それがテキストの代替メディアであること示すラベルが明確に付けられていない。このため、テキストに遭遇した利用者がその同期したメディアのバージョンを見つけるのは難しく、映像に遭遇した利用者は、そのテキストによる代替がどこにあるのかが分からない。

(今のところ、なし。)

検証

手順

テキストに対して同期したメディアによる代替を提供しているページを確認する。
同期したメディアが、代替メディアであって，明確にラベル付けされていることを確認する。

期待される結果

2. の結果が偽である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

F75: 達成基準 1.2.2 の失敗例－同期したメディアがページ上にある情報よりも多くの情報を提示するときに、キャプションなしで同期したメディアを提供している

適用 (対象)

あらゆるウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

達成基準 1.2.2 (キャプション (収録済) )
- クイックリファレンス 1.2.2 (キャプション (収録済) )
- 達成基準 1.2.2 (キャプション (収録済) )を理解する

解説

この失敗例の目的は、同期したメディアの代替が、代替のテキストよりも多くの情報を提供しているが、必要以上の情報にアクセスを提供するための独自のテキストによる代替を提供していないという状況を避けるためのものである。同期したメディアのほうがテキストよりも効果的なフォーマットである利用者にとっては、テキストの代替となる同期したメディアのほうが利用しやすい。テキストの代替となる同期したメディアは、テキストの代替コンテンツなので、キャプション形式の冗長なテキストによる代替、音声による説明又は完全なテキストによる代替をそれ自身のために用意する必要はない。その元となるテキストよりも多くの情報を同期したメディアが含んでいる場合は、単なるテキストの代替メディアというよりは、それ自体が同期したメディアのコンテンツとなる。こういった場合、キャプションの提供に関しては、達成基準 1.2.2 及び達成基準 1.2.3 の要件に従うものとする。

事例

(今のところ、なし。)

検証

手順

同期したメディアによる代替のキャプションを確認する。
同期したメディアによる代替が、テキストでページ上に示されている情報よりも多くの情報を提供していないことを確認する。
注記: 同期したメディアによる代替では、ページ上にあるのとは別の言葉を用いている場合がよくあるが、そのページのトピックについて新しい情報を提示すべきではない。

期待される結果

2.の結果が偽である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

F77: 達成基準 4.1.1 の失敗例－ ID 型の値が重複している

適用 (対象)

HTML5 及び、HTML4 と SVG を含むあらゆる XML ベースのマークアップ言語

訳注: HTML 4 (HTML 4.01) は Superseded Recommendation としてマークされ、廃止された仕様である。

これは、次の達成基準に関連する失敗例である:

達成基準 4.1.1 (構文解析)
- クイックリファレンス 4.1.1 (構文解析)
- 達成基準 4.1.1 (構文解析)を理解する

解説

この文書は、支援技術がコンテンツとやりとりをする際に、ID が重複しているエラーによって引き起こされる問題の失敗例について述べている。ID の値が重複していると、ユーザエージェントが ID を示す属性を用いてコンテンツのさまざまな部分間の関係性を正確に伝える際に問題となりうる。例えば、スクリーンリーダーは、ID の値を用いて、データテーブル内にあるデータセルの見出しとなるコンテンツを特定したり、ラベルのテキストと関連付けられているフォームの入力コントロールを特定したりすることがある。もし、それらの値が一意的ではなかった場合、スクリーンリーダーは、どの見出しがそのデータセルと関連付けられているのか、あるいはどのコントロールがどのラベル又は名前と関連付けられているのかを、プログラムで解釈できなくなってしまう。

その仕様でドキュメントをバリデートすることによって、ID の属性値がそのドキュメント内で一意的であることを確認する。なぜなら、どの属性がドキュメント全体にわたって一意的な識別子を有しているかは、仕様によって定められているからである。

注記 1: ほとんどのマークアップ言語では、例えば HTML 及び SVG においてそうであるように、ID の値は属性値である。

注記 2: ID を示す属性として xml:id 属性のみを用いる XML ドキュメントでは、xml:id の仕様をサポートするバリデータを用いて XML ドキュメントを解析すればよい。

事例

失敗例 1

コンテンツ制作者が、オンラインのバリデーションサービスを使って、すべての id 属性値が一意的であることをチェックしている。

失敗例 2

コンテンツ開発者が、オーサリングツールの機能を利用して、id 属性値が一意的であることを確認している。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

HTML 5: id attribute
HTML 4.01: id attribute
xml:id Version 1.0 - W3C Recommendation 9 September 2005.
Extensible Markup Language (XML) 1.0 (Fourth Edition): Validity constraint: ID

検証

手順

すべての ID の値がウェブページにおいて一意的である。

期待される結果

1. の結果が偽である場合、この失敗例が適用され、そのコンテンツは達成基準の失敗となる。

F78: 達成基準 2.4.7 の失敗例－視覚的なフォーカスインジケータを除去する又は不可視にするような方法で、要素のアウトライン及びボーダーをスタイル指定する

適用 (対象)

あらゆるウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

達成基準 2.4.7 (フォーカスの可視化)
- クイックリファレンス 2.4.7 (フォーカスの可視化)
- 達成基準 2.4.7 (フォーカスの可視化)を理解する

解説

この文書は、ユーザエージェントでデフォルトに指定されているキーボードフォーカスの視覚的なインジケーターが非表示になっている、又はコンテンツ制作者が提供する視覚的なフォーカスインジケーターが提供されずに、ページ上の他のスタイル指定により非表示にされる時に起こる失敗例の条件について述べている。フォーカスインジケーターを非表示に指定することで、ユーザエージェントはフォーカスインジケーターを表示しなくなる。他のスタイル指定によって、フォーカスインジケーターが提示されていても見づらくなることがある。例えばフォーカスのアウトラインと同じように見えるアウトライン、又はフォーカスインジケーターと同じ色になっているため識別できない太いボーダーといったものである。

事例

失敗例 1: CSS を用いて、フォーカスインジケーターを表示しないようにする

下記の CSS の事例では、デフォルトのフォーカスインジケーターを除去しているため、視覚的に認識可能なフォーカスインジケーターを提供するという要求に失敗となる。

コード例:

:focus {outline: none}

失敗例 2: 要素のアウトラインが、フォーカスインジケーターと視覚的に類似している

下記の CSS の事例は、リンクの周辺にフォーカスインジケーターと同じように見えるアウトラインを生成するものである。たとえユーザエージェントがフォーカスインジケーターを表示しているとしても、利用者にはどの要素が実際にフォーカスを持つのか判別できない。

コード例:

a {outline: thin dotted black}

失敗例 3: 要素が、フォーカスインジケーターを覆い隠すボーダーを持つ

下記の CSS の事例では、フォーカスインジケーターがボーダーの上に表示されたときに、フォーカスインジケーターに対してコントラストが十分でないボーダーをリンクの周辺に生成している。この場合、フォーカスインジケーターがボーダーのすぐ外側に表示されているが、両方とも黒で、ボーダーがフォカスインジケーターよりも太くなっている。これにより、「視覚的に認識可能」の定義を満たさない。

コード例:

a {border: medium solid black}

参考リソース

この達成方法に関する参考リソースはない。

検証

手順

キーボードを使ってページ上のすべてのフォーカス可能な要素にフォーカスを設定する。
フォーカスインジケーターが可視であることを確認する。

期待される結果

2. の結果が真である。

F79: 達成基準 4.1.2 の失敗例－プログラムによる解釈が可能ではない、又は変更の通知が利用可能ではないようなユーザインタフェースコンポーネントのフォーカス状態

適用 (対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- クイックリファレンス 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- 達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )を理解する

解説

あるユーザインタフェースコンポーネントにフォーカスがあるかどうかは、そのコンポーネントの状態 (state) の特に重要な一面である。多くの種類の支援技術が、キーボードフォーカスの現在位置を追跡することに依存している。スクリーンリーダーは、利用者の注視点をフォーカスの当たっているユーザインタフェースコンポーネントに移動させ、画面拡大ソフトはフォーカスが当たっているコンポーネントを見ることができるようにコンテンツの表示を変えていく。新しいコンポーネントにフォーカスが遷移した時に、支援技術に通知されなければ、利用者は意図と異なるコンポーネントとやりとりをしようとして混乱することになる。

通常ユーザエージェントが標準的なコンポーネントに対してこの機能で処理を行う一方、スクリプトで独自に記述されたユーザインタフェースコンポーネントは、アクセシビリティ API を用いてユーザエージェントがフォーカスについての情報及び通知を利用できるようにしなければならない。

事例

カスタムメニューがメニュー項目を明確に描画して表示している。マウス及びキーイベントを直接制御し、現在選択されているメニュー項目は反転表示となっている。プログラマーがフォーカスを持ったメニュー項目をアクセシビリティ API 経由で引き渡さないようにしたため、支援技術は、フォーカスがメニューの中のどこかにあることまでしか分からず、どのメニュー項目にフォーカスが当たっているのか決定できない。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

Accessible Explorer and Accessible Event Watcher

検証

手順

ウェブコンテンツ技術に対してアクセシビリティチェッカーを用い (又は、利用できない場合は、コードを検査する、又は支援技術で検証する)、コントロールがアクセシビリティ API を経由してフォーカスの状態 (state) を公開しているかどうかを確認する。
ウェブコンテンツ技術に対してアクセシビリティチェッカーを用い (又は、利用できない場合は、コードを検査する、又は支援技術で検証する)、フォーカスがあるコントロールから別のコントロールに遷移したとき、支援技術に通知されるかどうかを確認する。

期待される結果

1. 又は 2. の結果が偽である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

F80: 達成基準 1.4.4 の失敗例－視覚的にレンダリングされたテキストを 200% まで拡大するときに、テキストベースのフォームコントロールのサイズが変更されない

適用 (対象)

HTML、XHTML 及び CSS

これは、次の達成基準に関連する失敗例である:

達成基準 1.4.4 (テキストのサイズ変更)
- クイックリファレンス 1.4.4 (テキストのサイズ変更)
- 達成基準 1.4.4 (テキストのサイズ変更)を理解する

解説

この失敗例の条件の目的は、テキストのサイズ変更が、それに応じてテキストベースのフォームコントロールを拡大しない時に発生する問題を説明するものである。テキストは利用者が要求するテキストサイズで表示されないので、利用者がテキストの入力及び入力したものを読むのに苦労するかもしれないことを意味している。

テキストベースのフォームコントロールは、ボタンと同様に入力ボックス (テキスト及びテキストエリア) を含んでいる。

事例

失敗例 1: お問い合わせフォーム

お問い合わせフォームは、いくらかの前置き情報、及び利用者が名、姓、電話番号及び電子メールアドレスを入力するためのフォームコントロールがある。見出し、前置きのテキスト及びフォームコントロールのラベルは、拡張性のある方法で実装されているが、フォームのコントロール自体は拡張性のある方法では実装されていない。

XHTML コンポーネント:

コード例:

 <h1>Contact Us</h1>
 <p>Please provide us with your details and we will contact you as soon as we can. Note that all of the form fields are required.</p>
 <label for="fname">First Name</label><input type="text" name="fname" id="fname" /><br />
 <label for="lname">Last Name</label><input type="text" name="lname" id="lname" /><br />
 <label for="phone">Telephone</label><input type="text" name="phone" id="phone" /><br />
 <label for="email">Email</label><input type="text" name="email" id="email" /><br />
 <input type="submit" name="Submit" value="Submit" id="Submit" />

CSS:

コード例:


h1 { font-size: 2em; }
 p, label { font-size: 1em; }
 input {font-size: 12pt}

参考リソース

この達成方法に関する参考リソースはない。

(今のところ、なし。)

検証

手順

利用者が入力したテキストを受け取るテキストベースのフォームコントロールにテキストを入力する。
200％までコンテンツのテキストサイズを拡大する。
テキストベースのフォームコントロール内のテキストが 200％まで拡大したことを確認する。

期待される結果

3．の結果が偽である場合、失敗例の条件は適用され、コンテンツはこれらの達成基準の失敗となる。

F81: 達成基準 1.4.1 の失敗例－色の違いだけで、必須又はエラーフィールドを特定している

適用 (対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

達成基準 1.4.1 (色の使用)
- クイックリファレンス 1.4.1 (色の使用)
- 達成基準 1.4.1 (色の使用)を理解する

解説

この文書は、フォームの必須項目又はエラー項目が色の違いだけで示されていて、その必須項目又はエラー項目を特定するその他の方法がないことによる失敗例について述べている。全盲又は色覚異常の利用者は、どれが必須項目で、どれがエラー項目なのかを示す色の違いを知覚できないため、そのような利用者にとっては問題となる恐れがある。

事例

利用者がオンラインフォームを入力していて、電話番号が必須項目である。電話番号のテキストフィールドへの入力が必須であることを示すために、「電話番号」というラベルが赤のテキストだけで示されており、「電話番号」が必須項目であることを示すものが他にはない。全盲又は色覚異常の利用者は、「電話番号」が必須項目であることを確認できないかもしれない。
利用者が必須項目を入力しないままオンラインフォームを送信してしまい、エラーになった。エラーになったフォームの入力項目が赤のテキストだけで示されていて、その入力項目がエラーであることが色以外の方法では示されていない。

注記: どちらの事例でも、もしテキストが視覚的提示において、たとえ色が取り除かれたとしても周辺のテキストから容易に区別される十分な差異があるなら(例えば太字や異なるフォントなど)、色は失敗なしで使用されうる。もしモノクロで見たなら、容易に異なって見えるだろう他のテキストと選択された色が十分な輝度の差 (明るさ) を持つなら、同様に失敗しないだろう。これらの場合、情報は色 (色相) だけではなく、それぞれ「提示」又は「明るさ」で表示されている。

検証

手順

色の違いで特定される、ウェブページで全ての必須フィールド又はエラーフィールドに対して:

必須フィールド又はエラーフィールドであることを特定するための色以外の方法が提供されていることを確認する。

期待される結果

1.の結果が偽である場合、この失敗例が適用され、そのコンテンツは達成基準の失敗となる。

F82: 達成基準 3.3.2 の失敗例－電話番号のフィールド一式を視覚的にフォーマットしているが、テキストラベルを含んでいない

適用 (対象)

あらゆるウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

達成基準 3.3.2 (ラベル又は説明)
- クイックリファレンス 3.3.2 (ラベル又は説明)
- 達成基準 3.3.2 (ラベル又は説明)を理解する

解説

この文書では、視覚障害、又は認知障害のある利用者が、電話番号入力欄であることを認識し、フィールドにどのような情報を入力すればよいかを理解できない失敗例について述べている。電話番号は多くの場合、固定の、特有の書式で示されるため、コンテンツ制作者は電話番号入力欄であることを示すにはフィールドに視覚的な書式を設定すれば十分であると考えているかもしれない。しかし、全てのフィールドがプログラムによる解釈が可能な名前 (name) を持っている場合においても、テキストラベルでフィールドの一式を電話番号として特定するようにしなければならない。

事例

失敗例 1

アメリカ合衆国では、電話番号は 3 桁の市外局番と 3 桁の市内局番、及び 4 桁の番号に区切られている。あるウェブページ上で電話番号の三つの部分に対して固定長のテキスト入力フィールドを作成し、最初のフィールドをカッコで囲い、ダッシュ「-」で 2 番目と 3 番目のフィールドを区切っている。この書式から、利用者はフィールドを電話番号として認識するが、そのウェブページではそれが電話番号であることを示すテキストラベルがつけられていない。それぞれのフィールドのラベルはその直前にあるテキストであることが多いので、三つのフィールドのラベルはそれぞれ「(」、「)」と「-」ということになってしまう。

検証

手順

一つの電話番号を表すウェブページ上の電話番号フィールド一式に対して、電話番号フィールド一式が近くに配置された目に見えるテキストラベルでラベル付けされていることを確認する。
一つの電話番号を表すウェブページ上の電話番号フィールド一式に対して、フィールドへの入力方法の説明がある。

期待される結果

1. と 2. の両方の結果が偽である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

F83: 達成基準 1.4.3 及び 1.4.6 の失敗例－前景のテキスト (又は文字画像) との十分なコントラストを提供しない背景画像を使用している

適用 (対象)

あらゆるウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この失敗例は、弱視の利用者が背景画像の上に表示されているテキストを読むことができない場合に関するものである。背景画像とテキストのコントラストが十分ではない時、背景画像はテキストと混同し、正確に読むことを困難にさせることがある。

達成基準 1.4.3 と 1.4.6 を満たすためには、テキストとその背景画像の間に十分なコントラストを確保しなければならない。画像に対して、これはテキストの背後にあってテキストにとても似ている画像の一部とテキストの間に十分なコントラストが必要であることを意味している。

事例

失敗例 1

黒いテキストが黒い線の画像と重なっている。その線は文字の背景にあり、F's をまるで E's のように見せている。

失敗例 2

黒いテキストが濃い灰色の場所のある画像と重なっている。テキストが濃い灰色のどこの場所で交差していても、コントラストがとても不十分なため、テキストを読むことができない。

検証

手順

クイックチェック: まず初めに、テキストとその場所の一番暗い部分 (色の濃いテキストに対して) 又は一番明るい部分 (色の明るいテキストに対して) との間のコントラストが達成基準 (1.4.3 又は 1.4.5) による要求事項を満たしている、又は上回っていることを確認する。コントラストが指定されたコントラストを満たす又は超える場合、失敗はない。
クイックチェックが偽である場合、各文字の背後にある背景がその文字と十分なコントラストがあるかどうかを確認する。

期待される結果

クイックチェックが偽かつ 2. の結果も同様に偽である場合、この失敗例の条件は適用され、コンテンツはコントラストの達成基準の失敗となる。

F84: 達成基準 2.4.9 の失敗例－リンクテキストを具体的なテキストに変更するメカニズムなしで、「ここをクリック」又は「続きを読む」などの不明確なリンクを使用している

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する失敗例である:

達成基準 2.4.9 (リンクの目的 (リンクのみ) )
- クイックリファレンス 2.4.9 (リンクの目的 (リンクのみ) )
- 達成基準 2.4.9 (リンクの目的 (リンクのみ) )を理解する

解説

この失敗例は、「ここをクリック」又は「続きを読む」などのアンカー要素として使用されるリンクがあり、そのリンクは、目的を理解するために周囲のテキストを必要とし、かつリンクテキストを拡張するためのボタンなど目的地を自身で明確にするメカニズムがないという、よくある状況を説明する。

スクリーンリーダーを使用する全盲の利用者は、ページ内にあるリンクの一覧を表示したダイアログボックスを呼び出すことがある。彼らは、行き先を決定するためにこのリンクの一覧を使用する。しかし、その一覧の中の多くのリンクが、「ここをクリック」又は「続きを読む」とだけしか読上げられないのであれば、主要なナビゲーション方式であるこの機能をスクリーンリーダーで使用することができなくなる。このような理由から、リンクテキストのみでリンク先を知ることができる方法を一つも提供していないと、達成基準 2.4.9 の失敗例となるのである。こうした状況は、リンクを Tab キーで移動する利用者にも当てはまる。ウェブページ内を Tab キーで移動しているとき、「ここをクリック」、「ここをクリック」、「ここをクリック」としか聞こえてこなかったとしたら、利用者は困惑してしまうだろう。

事例

失敗例 1

コード例:

<a href="file110.htm">Click here</a> for more information on the Rocky Mountains.

失敗例 2

コード例:

<h2>News headlines</h2>
The middle east peace meetings have yielded fruitful dialogue. 
<a href="r4300.htm">read more</a>

検証

手順

ページにある個々のリンクを検証する。
リンクの目的が、周囲のテキストから判別できるが、リンクテキストからだけでは判別できない、「ここをクリック」又は「続きを読む」といったリンク先の分からないリンクテキストがあるかどうかを確認する。
ページ内にあるリンク先の分からないリンク全てを、リンク先の分かるリンクテキストに変えるメカニズムがページ内にあるかどうかを確認する。

期待される結果

手順 2.の結果が真でありかつ、3.の結果が偽である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

F85: 達成基準 2.4.3 の失敗例－連続するナビゲーション順序において、トリガーとなるコントロールに隣接していないダイアログ又はメニューを使用している

適用 (対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

達成基準 2.4.3 (フォーカス順序)
- クイックリファレンス 2.4.3 (フォーカス順序)
- 達成基準 2.4.3 (フォーカス順序)を理解する

解説

この文書では、連続するナビゲーション順序の中での順番が原因で、キーボードだけで操作している利用者がウェブページ上に実装されたダイアログ又はメニューのインタフェースコンポーネントの操作が困難になってしまう失敗例について述べている。ボタン又はリンクを起動してウェブページ上のダイアログ又はメニューを開いたとき、利用者の次の行動は、ダイアログ又はメニューを操作することである。もしフォーカスがダイアログ又はメニューに設定されていないと、連続するナビゲーション順序の中で、トリガーとなるコントロールと連続していない場合、キーボードだけで操作している利用者がダイアログ又はメニューを操作することが困難になる。

事例

失敗例 1: ウェブページ上のダイアログ又はメニューが連続するナビゲーション順序の最後に追加されている

DHTML のメニュー又はダイアログは、起動されると、動的に生成され、視覚的にはトリガーの近くに配置され、DOM の最後に付け加えられる。DOM の最後に付け加えられるため、連続するナビゲーション順序の最後となる。利用者は、メニュー又はダイアログを操作するまでに、ページ上の残りの部分をタブ操作で進んで行かなければならない。

失敗例 2: ページ上に実装されたメニューを閉じるとフォーカスがドキュメントに設定される

メニューが閉じられるとき、メニューはウェブページから削除又は隠されてフォーカスはドキュメントの先頭に設定される。利用者はメニューを開いた場所までナビゲーション順序の最初からタブを操作しなおさなければならない。

SCR26: 動的なコンテンツを、Document Object Model の、そのトリガーとなる要素の直後に挿入する

検証

手順

トリガーとなるコントロールによって開くウェブページ上に埋め込まれた各メニュー又はダイアログに対して:

トリガーとなるコントロールをキーボードで起動させる。
- a. メニュー又はダイアログにフォーカスがあるかどうかを確認する。
- b. 連続するナビゲーション順序においてフォーカスを進めていくと、メニュー又はダイアログにフォーカスが置かれるかどうかを確認する。
メニュー又はダイアログを閉じる。
- a. トリガーとなるコントロールにフォーカスがあるかどうかを確認する。
- b. 連続するナビゲーション順序においてフォーカスを後ろに戻すと、トリガーとなるコントロールにフォーカスが置かれるかどうかを確認する。

期待される結果

手順 1a. 及び 1b. の結果が両方とも偽である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。
手順 2a. 及び 2b. の結果が両方とも偽である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

F86: 達成基準 4.1.2 の失敗例－アメリカの電話番号など、複数に分けられたテキストフィールドのそれぞれに対して、名前 (name) が提供されていない

適用 (対象)

全般

これは、次の達成基準に関連する失敗例である:

達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- クイックリファレンス 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )
- 達成基準 4.1.2 (名前 (name) ・役割 (role) 及び値 (value) )を理解する

解説

これは、複数のテキストフィールドから成るフォームの入力項目で、その一部又は全部に名前 (name) がないことによる達成基準 4.1.2 の失敗例について述べている。多くの場合、複数のテキストフィールドから成るフォームの入力項目の全体に対してラベルが一つあり、そのラベルが最初のテキストフィールドに対してプログラム的に関連付けられているか、又はどのテキストフィールドに対してもプログラム的に関連付けられていない必要がある。

注記: 名前 (name) は、必ずしも視覚的に表示しなければならないわけではないが、支援技術に対しては明示されている必要がある。

事例

失敗例 1

米国の電話番号は、3 桁の市外局番、3 桁の市内局番、それに続く 4 桁の番号で構成されている。通常はこれが、例えば (206) 555-1212 のように、(市外局番) 市内局番-番号というフォーマットで示される。多くの場合、電話番号の記入を求めるフォームは三つのテキストフィールドに分かれているが、次の例ではラベルが一つしかない。


電話番号: 
(<input type="text" size="3">) <input type="text" size="3">-<input type="text" size="4">

この不適合となる事例は、アクセシビリティ API に三つのテキストフィールドそれぞれに対する名前 (name) がない場合に生じる。支援技術を使っている利用者は、三つの不明確なテキストフィールドを提示されることになる。また、三つのテキストフィールドから成る米国の電話番号の場合、一部の支援技術は、一つ目のフィールドを「(」、二つ目のフィールドを「)」、三つ目のフィールドを「-」とラベル付けすることがあり、これも決して利用者の役に立つものではない。

失敗例 2

同じく米国の電話番号で、この事例では、ラベルがプログラム的にどの部分にも関連付けられていない。


電話番号:
(<input type="text" size="3">) <input type="text" size="3">-<input type="text" size="4">

支援技術を使っている利用者は、三つの不明確なテキストフィールドを提示されることになる。

失敗例 3

同じく米国の電話番号で、この例では、ラベルが一つめのテキストフィールドにプログラム的に関連付けられている。


<label for="area">電話番号:</label> 
(<input id="area" type="text" size="3">) <input type="text" size="3">-<input type="text" size="4">

支援技術を使っている利用者は、一つめのテキストフィールドが電話番号全体のためのテキストフィールドであると理解し、二つめと三つめは不明確なテキストフィールドとして認識することになる。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

Microsoft Active Accessibility 2.0 SDK. Includes Inspect32.exe and other MSAA tools.
Gnome Accessibility Toolkit documentation
Microsoft Internet Explorer Developer Toolbar. Allows examination of script-generated DOM in Microsoft Internet Explorer.
Firebug. Allows examination of script-generated DOM in Firefox.

訳注 2: Firefox のアドオン「Firebug」は開発が終了している。代わりに開発ツールを使用できる。開発ツール | MDN も参照のこと。

訳注 3: Google Chrome の場合、類似のツールが利用できる。詳細については、Chrome DevTools | Tools for Web Developers | Google Developers を参照のこと。

訳注 4: Edge の場合も、類似のツールが利用できる。詳細については、Microsoft Edge Developer Tools - Microsoft Edge Development | Microsoft Docs を参照のこと。

検証

手順

マルチパートフォームフィールドにある各サブフィールドについて:

フィールドにプログラムによる解釈される名前 (name) があることを確認する。

期待される結果

1. の結果がどのサブフィールドでも偽になる場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

F87: 達成基準 1.3.1 の失敗例－ CSS の :before 及び :after 疑似要素並びに 'content' プロパティを用いて、非装飾のコンテンツを挿入している

適用 (対象)

CSS をサポートする全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

ユーザエージェント及び支援技術によるサポート

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>Do you think he's going to make it?</q>
</p>
<p class="mary">
 <q>It's not looking good.</q>
</p>

失敗例 2

この例では、:before を用いて、意見と事実の違いを区別している。

CSS は、次のようになっている。

コード例:

p.fact:before { content: "Fact: "; font-weight: bold; }
 p.opinion:before { content: "Opinion: "; font-weight: bold; }

これが、次のように使われている。

コード例:

 <p class="fact">
 The defendant was at the scene of the crime when it occurred. 
</p>
<p class="opinion">
 The defendant committed the crime. 
</p>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

CSS 2.1: Generated content, automatic numbering, and lists

訳注: Selectors Level 3 §7.4. The ::before and ::after pseudo-elements も参照のこと。この仕様の記述が、「CSS 2.1: Generated content, automatic numbering, and lists」に取って代わることに注意されたい。

F3: 達成基準 1.1.1 の失敗例－重要な情報を伝える画像を付加するために、CSS を使用している

検証

手順

:before 及び :after 疑似要素並びに content プロパティを用いて挿入されている全てのコンテンツを探し出す。
コンテンツが、装飾を目的にしたものであることを確認する。
挿入されたコンテンツが装飾を目的にしたものではない場合、その情報が支援技術に対して提供されており、CSS をオフにした際にも入手可能であることを確認する。

期待される結果

2. 又は 3. の結果が偽である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

F88: 達成基準 1.4.8 の失敗例－両端揃え (左右両方のマージンを揃える) のテキストを使用している

適用 (対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

達成基準 1.4.8 (視覚的提示)
- クイックリファレンス 1.4.8 (視覚的提示)
- 達成基準 1.4.8 (視覚的提示)を理解する

解説

認知障害のある利用者の多くは、両端揃え (左右両端を揃えた配置) されたテキストのブロックで重大なトラブルに陥ることがある。単語間のスペースによって、ページ上を流れる「リバー (rivers of white)」ができる。それによって、一部の人々はテキストを読むことが困難になる。この失敗例は、この混乱させるテキストレイアウトが発生する状況について説明している。この問題を回避する最良の方法は、両端揃え (左右両端を揃えた配置) されたテキストレイアウトにしないことである。

事例

失敗例 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>

C22: テキストの視覚的提示を制御するために、CSS を使用する

検証

手順

一般的なブラウザでページを開く。
コンテンツが両端揃え (左右両端を揃えた配置) されていないことを確認する。

期待される結果

手順 2. の結果が偽である場合、この失敗例の条件は適用され、コンテンツは達成基準 1.4.8 の失敗となる。

F89: 達成基準 2.4.4、達成基準 2.4.9、及び達成基準 4.1.2 の失敗例－リンクで唯一のコンテンツである画像にアクセシブルな名前 (accessible name) が提供されていない

適用 (対象)

リンクを提供するコンテンツ

これは、次の達成基準に関連する失敗例である:

解説

この文書は、画像のような非テキストコンテンツのみで提供されているリンクについて、そしてそのリンクがアクセシブルな名前で特定できないときに起こる失敗例について述べている。リンクのアクセシブルな名前 (name) は Accessible Name Calculation によって決定される。

これはテキスト及び画像が同じリンク先に別々にリンクしている場合にも適用される。このケースでは、実装方法 H2: 同じリソースに対して隣接する画像とテキストリンクを結合する (HTML) は別々のリンク及び望ましくない冗長性を減少させるのに推奨される方法である。

事例

失敗例 1: HTML 検索結果

検索サイトは、試合のサイトへのテキストリンク及びイメージリンクの両方を含んだ検索結果を返す。検索結果には既にテキストリンクがあるため、画像の alt 属性は空になっている。しかし、スクリーンリーダーは画像リンクを無視しないで、リンクの目的が説明されていそうなテキストを見つけるための推測に基づいた修復を試みる。例えば、スクリーンリーダーは「フットボールドットジフフットボールスコアカード」と読み上げるかもしれない。

コード例:

 <a href="scores.html">
   <img src="football.gif" alt="" />
 </a>
 <a href="scores.html">
   Football Scoreboard
 </a>
}

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

手順

リンクが非テキストコンテンツのみを含むかどうかを確認する。
非テキストコンテンツが、role="presentation" 又は alt=""を用いるなど、支援技術により無視される方法で実装されているかどうかを確認する。
そのリンクに、aria-label 又は aria-labelledby のような他の方法でアクセシブルな名前 (name) が提供されていないことを確認する。

期待される結果

上記の全ての結果が真である場合、この失敗例の条件は適用され、コンテンツは達成基準の失敗となる。

F90: 達成基準 1.3.1 の失敗例－ headers 属性及び id 属性によってテーブルの見出しとコンテンツが不正確に関連付けられている

適用 (対象)

HTML 及び XHTML。

これは、次の達成基準に関連する失敗例である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

解説

コンテンツ制作者にとってデータセルと見出しセルを明示的に関連付けるひとつの方法は id 属性及び headers 属性を使用することである。これによりコンテンツ制作者は複数の見出しセルに特定のデータセルを関連付けられる。これは複数の見出しをレベルをもつ複雑なデータテーブルの場合に必要になる。

この失敗例は、データセルと対応する見出しセルとの関係が、id 属性と headers 属性の関連付けが不完全であるため、正しくプログラムによる解釈が可能でない場合に発生する。例えば、テーブルのコードをコピーしたりコードのアップデートを忘れたときにおこる。

事例

H43: データテーブルのデータセルを見出しセルと関連付けるために、id 属性及び headers 属性を使用する (HTML) の例 1 のような複雑なデータテーブルが存在することによる。

失敗例 1: ネストされた見出しと正しく関連付けられていないテーブルコンテンツ

この例では、ネストされた見出しが使われているが、コンテンツのセルは id 属性及び headers 属性によって正しく関連付けられていない。全セルは「Exams」(id="e") のようなトップレベル見出しを参照する - これは「Projects」見出しを参照すべき最後の三つのセルにとって正しくない。また、第 2 レベルの列見出しの参照はコンテンツ (1, 2, Final) が繰り返されるようなこちらの例と違いはなくても、誤って取り違えられる。

Example Code:


<table>
   <tr>
     <th rowspan="2" id="h">Homework</th>
     <th colspan="3" id="e">Exams</th>
     <th colspan="3" id="p">Projects</th>
   </tr>
   <tr>
     <th id="e1" headers="e">1</th>
     <th id="e2" headers="e">2</th>
     <th id="ef" headers="e">Final</th>
     <th id="p1" headers="p">1</th>
     <th id="p2" headers="p">2</th>
     <th id="pf" headers="p">Final</th>
   </tr>
   <tr>
     <td headers="h">15%</td>       
     <td headers="e p1">15%</td>  // should be "e e1"
     <td headers="e p2">15%</td>  // should be "e e2"
     <td headers="e pf">20%</td>  // should be "e ef"
     <td headers="e e1">10%</td>  // should be "p p1"
     <td headers="e e2">10%</td>  // should be "p p2"
     <td headers="e ef">15%</td>  // should be "p pf"
   </tr>
</table>

Failure example of table incorrectly associating headers attributes in table content (td) to table headers (th).

検証

手順

データセルが id 属性及び header 属性によって見出しセルと関連付けられたテーブルの場合、プログラム的な関連付けが正しいことを確認する。

期待される結果

1. の結果が偽である場合、この失敗条件は適用され、コンテンツは達成基準の失敗となる。

F91: 達成基準 1.3.1 の失敗例－テーブルの見出しを正しくマークアップしていない

適用 (対象)

HTML 及び XHTML。

これは、次の達成基準に関連する失敗例である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

ユーザエージェント及び支援技術によるサポート

F91 に関するユーザエージェントサポートノートを参照のこと。

解説

この失敗例は、データテーブルが、テーブルコンテンツの内側からプログラムによる解釈が可能な見出しを作成するために、見出し要素 (th) 又はほかの適切なテーブルマークアップ (scope) 属性、headers 及び id 又は ARIA ロール columnheader / rowheader) を使用しないときに起こる。データセルがヘッダー情報とともにのみ明瞭である場合、ヘッダーをプログラムによる解釈が可能にすることは、特に重要である。スクリーンリーダーの利用者がテーブルコンテンツを水平又は垂直にナビゲートする場合、データセル内の情報に必要な文脈を提供するために変更された見出しを読み上げることができる。

事例

失敗例 1: 見出しが適切にマークアップされていない

このテーブルは見出しとして th (あるいはほかの適切な見出しマークアップ) を使っていない。かわりに、すべてのセルに td 要素が使われている。セルからセルへ移動するのに、スクリーンリーダーは見出しセルに関連付けられたコンテンツの読み上げにしばしば失敗する。

Example Code:


<table>
   
   <tr>
      <td>Name</td>
      <td>Age</td>
      <td>Height (cm)</td>
      <td>Weight (kg)</td>
   </tr>   
   
   <tr>
      <td>Linda</td>
      <td>33</td>
      <td>169</td>
      <td>59</td>
   </tr>   
   
   <tr>
      <td>Jack</td>
      <td>37</td>
      <td>184</td>
      <td>74</td>
   </tr>    
   
   <tr>
      <td>Kira</td>
      <td>8</td>
      <td>120</td>
      <td>21</td>
   </tr>   
   
   <tr>
      <td>Daniel</td>
      <td>3</td>
      <td>79</td>
      <td>14</td>
   </tr>  
</table>

View example 1 (opens in same browser window)

検証

手順

全てのデータテーブルについて、次のいずれかのメカニズムを用いて、テーブル見出しが正しくプログラムによる解釈が可能かどうかを確認する:

テーブル見出し要素 (th) でマークアップされた見出し
テーブル見出しが 1 行より多い又は 1 列より多いテーブルの th における scope 属性
テーブル見出しが 1 行より多い又は 1 列より多いテーブルの th における scope 属性
headers 属性と id 属性を用いて関連付けられた見出し及びデータのセル
scope 属性を持つ td 要素としてマークアップされた見出し
ARIA ロールの rowheader 属性又は columnheader 属性でマークアップされた見出し

訳注: 2 と 3 は全く同一の内容であるが、原文ママである。

期待される結果

上記の全ての結果が偽である場合、この失敗条件は適用され、コンテンツは達成基準の失敗となる。

F92: 達成基準 1.3.1 の失敗例－セマンティックな情報を伝えるコンテンツに presentation ロールを使用している

適用 (対象)

HTML 及び XHTML

これは、次の達成基準に関連する失敗例である:

達成基準 1.3.1 (情報及び関係性)
- クイックリファレンス 1.3.1 (情報及び関係性)
- 達成基準 1.3.1 (情報及び関係性)を理解する

解説

この失敗例は、presentation の役割 (role) が情報又はコンテンツの関係性を伝達することを目的とする要素に適用されるときに起こる。table のような要素はセマンティックなマークアップによってコンテンツがもつ情報を伝達することができる。一方 WAI-ARIA の "presentation" のロールは、アクセシビリティ API からコンテンツのセマンティックな情報を抑制し、利用者への情報の伝達をユーザエージェントが行わないよう意図されている。"presentation" ロールをセマンティックな情報を伝達するべきコンテンツに用いるのは利用者のコンテンツの理解を妨げるだろう。

事例

失敗例 1:

この例では、表のデータは role=presentation でマークアップされている。そのようなレイアウトテーブルのデザインのマークアップに関わらず、データテーブルはセマンティックな情報を維持する必要がありそれゆえ role=presentation でマークアップされるべきではない。

例:


<table role="presentation">
   <caption>Fruits and their colors</caption>
   <tr>
     <th>Name</th>
     <th>Color</th>
   </tr>
   <tr>
    <td scope="row">banana</td>
    <td>yellow</td>
   </tr>
   <tr>
    <td scope="row">orange</td>
    <td>orange</td>
   </tr>
  </table>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

The Roles Model

検証

手順

セマンティックなマークアップを通じて情報、構造又は関係性を伝える要素かどうかを確認する
要素が role="presentation" 属性を持っている

期待される結果

2. の結果が真である場合、の失敗条件は適用され、コンテンツは達成基準の失敗となる。

F93: 達成基準 1.4.2 の失敗例－自動再生する HTML5 のメディア要素を一時停止又は停止する方法がない

適用 (対象)

HTML5

これは、次の達成基準に関連する失敗例である:

達成基準 1.4.2 (音声の制御)
- クイックリファレンス 1.4.2 (音声の制御)
- 達成基準 1.4.2 (音声の制御)を理解する

解説

この失敗例は、audio あるいは video 要素が autoplay 属性をもつ音声トラックを含むときや、muted 属性を含まなかったり、メディアの停止または一時停止のコントロール機能かコマンドがないときに起きる。

autoplay 属性が存在している場合、ユーザエージェントはできる限り停止させずに自動的にメディアの再生をはじめる。muted 属性がもし存在していたら、ユーザエージェントは最初にメディアの音声出力を無音にし、ユーザ設定で上書きする。

メディア要素が 3 秒より短い場合、失敗例は起こらない。ユーザエージェントが autoplay の挙動を上書きする利用者設定を提供する場合、失敗例は起こらない。

HTML 仕様は次の注記を含んでいる:

ユーザエージェントは autoplay をサポートする必要はなく、ユーザエージェントがその問題に関する利用者設定を尊重することが示唆される。コンテンツ制作者は、必要に応じて利用者がその動作を上書きできるようにするために、スクリプトを使用して動画を再生させるよりむしろ autoplay 属性を使用することが促される。
利用者が望まない場合、例えばスクリーンリーダーを使用する場合に、利用者が自動再生を上書きすることができるとき、コンテンツ制作者は、自動再生をトリガーするためにスクリプトを使用するよりもむしろ、autoplay 属性を使用することが促される。コンテンツ制作者はまた、自動再生の動作を一切使用せずに、ユーザエージェントを　明示的な再生をするために利用者を代わりに待つことも勧められる。

事例

事例 1: 音声の自動再生

この例では、動画広告が音声トラックを含む。動画は loop 属性をもっているため連続再生され、動画は autoplay 属性のため及び利用者が動画を停止できるどんなコントロール方法もないために自動的に開始される。

コード例:


				 <video src="ads.cgi?kind=video" autoplay loop></video>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

(今のところ、なし。)

検証

手順

audio 又は video 要素がアクティブな音声トラックを持つかどうかを確認する。
音声又は動画が 3 秒より長く続くかどうかを確認する。
要素が autoplay 属性を持っているかどうかを確認する。
要素が muted 属性を持っていないかどうかを確認する。
メディア要素を停止又は一時停止するためのコマンド又はコントロール方法を持っていないかどうかを確認する。

期待される結果

1 から 5 までの結果が真である場合、この失敗例の条件が適用され、コンテンツは達成基準の失敗となる。

附録 A: 謝辞

この出版物は、初期は契約番号 ED-OSE-10-C-0067、現在は契約番号 HHSP23301500054C のもとで米国教育省・障害者リハビリテーション研究所 (NIDILRR) の政府資金によって一部賄われている。この出版物の内容は、必ずしも米国教育省の見解や政策を反映するものではなく、また商品名、商用製品、組織の言及は米国政府による支持を意味するものではない。

Web Content Accessibility Guidelines ワーキンググループ (WCAG WG) への参加に関する情報は、Working Group home page で提供している。

A.1 この文書の作成に貢献した WCAG WG の参加者

Paul Adam (Deque)
Kathleen Anderson
Jon Avila (SSB Bart Group)
Bruce Bailey (U.S. Access Board)
Laura Carlson
Louis Cheng (Google)
Michael Cooper (W3C)
Wayne Dick
Eric Eggert (W3C)
Michael Elledge
Detlev Fischer
John Foliot (Deque)
Loretta Guarino Reid (Google)
Jon Gunderson
Katie Haritos-Shea
Marc Johlic (IBM)
Barry Johnson (Deque)
Andrew Kirkpatrick (Adobe)
David MacDonald
Erich Manser (IBM)
James Nurthen (Oracle)
Joshue O Connor
Jan Richards
Alan Smith
Adam Solomon
Makoto Ueki
Gregg Vanderheiden
Kathleen Wahlbin
Can Wang (Zhejiang University)
Jason White (Educational Testing Service)
Kenny Zhang (W3C)

A.2 過去の WCAG WG 参加者及び WCAG 2.0 又は関連文書への貢献者

Shadi Abou-Zahra, Jim Allan, Jenae Andershonis, Wilhelm Joys Andersen, Andrew Arch, Avi Arditti, Aries Arditi, Jon Avila, Mark Barratt, Mike Barta, Sandy Bartell, Kynn Bartlett, Chris Beer, Charles Belov, Marco Bertoni, Harvey Bingham, Chris Blouch, Paul Bohman, Frederick Boland, Denis Boudreau, Patrice Bourlon, Judy Brewer, Andy Brown, Dick Brown, Doyle Burnett, Raven Calais, Ben Caldwell, Alastair Campbell, Laura Carlson, Tomas Caspers, Roberto Castaldo, Sofia Celic-Li, Sambhavi Chandrashekar, Mike Cherim, Jonathan Chetwynd, Wendy Chisholm, Alan Chuter, David M Clark, Joe Clark, Darcy Clarke, James Coltham, Vivienne Conway, Earl Cousins, James Craig, Tom Croucher, Pierce Crowell, Nir Dagan, Daniel Dardailler, Geoff Deering, Sébastien Delorme, Pete DeVasto, Wayne Dick, Iyad Abu Doush, Sylvie Duchateau, Cherie Eckholm, Roberto Ellero, Don Evans, Gavin Evans, Neal Ewers, Steve Faulkner, Bengt Farre, Lainey Feingold, Wilco Fiers, Michel Fitos, Alan J. Flavell, Nikolaos Floratos, Kentarou Fukuda, Miguel Garcia, P.J. Gardner, Alistair Garrison, Greg Gay, Becky Gibson, Al Gilman, Kerstin Goldsmith, Michael Grade, Karl Groves, Jon Gunderson, Emmanuelle Gutiérrez y Restrepo, Brian Hardy, Eric Hansen, Benjamin Hawkes-Lewis, Sean Hayes, Shawn Henry, Hans Hillen, Donovan Hipke, Bjoern Hoehrmann, Allen Hoffman, Chris Hofstader, Yvette Hoitink, Martijn Houtepen, Carlos Iglesias, Jonas Jacek, Ian Jacobs, Phill Jenkins, Duff Johnson, Jyotsna Kaki, Shilpi Kapoor, Leonard R. Kasday, Kazuhito Kidachi, Ken Kipness, John Kirkwood, Jason Kiss, Johannes Koch, Marja-Riitta Koivunen, Maureen Kraft, Preety Kumar, Kristjan Kure, Andrew LaHart, Gez Lemon, Chuck Letourneau, Aurélien Levy, Harry Loots, Scott Luebking, Tim Lacy, Jim Ley, Alex Li, William Loughborough, Greg Lowney, N Maffeo, Mark Magennis, Kapsi Maria, Luca Mascaro, Matt May, Sheena McCullagh, Liam McGee, Jens Meiert, Niqui Merret, Jonathan Metz, Alessandro Miele, Steven Miller, Mathew J Mirabella, Matt May, Marti McCuller, Sorcha Moore, Mary Jo Mueller, Charles F. Munat, Robert Neff, Charles Nevile, Liddy Nevile, Dylan Nicholson, Bruno von Niman, Tim Noonan, Sebastiano Nutarelli, Graham Oliver, Sean B. Palmer, Sailesh Panchang, Devarshi Pant, Nigel Peck, Anne Pemberton, David Poehlman, Ian Pouncey, Charles Pritchard, Kerstin Probiesch, W Reagan, Adam Victor Reed, Chris Reeve, Chris Ridpath, Lee Roberts, Mark Rogers, Raph de Rooij, Gregory J. Rosmaita, Matthew Ross, Sharron Rush, Joel Sanda, Janina Sajka, Roberto Scano, Gordon Schantz, Tim van Schie, Wolf Schmidt, Stefan Schnabel, Lisa Seeman, Cynthia Shelly, Glenda Sims, John Slatin, Becky Smith, Jared Smith, Andi Snow-Weaver, Neil Soiffer, Jeanne Spellman, Mike Squillace, Michael Stenitzer, Diane Stottlemyer, Christophe Strobbe, Sarah J Swierenga, Jim Thatcher, Terry Thompson, Justin Thorp, David Todd, Mary Utt, Jean Vanderdonckt, Carlos A Velasco, Eric Velleman, Gijs Veyfeyken, Dena Wainwright, Paul Walsch, Daman Wandke, Richard Warren, Elle Waters, Takayuki Watanabe, Léonie Watson, Gian Wild, David Wooley, Wu Wei, Leona Zumbo.

附録 B: リファレンス

CSS1: "Cascading Style Sheets, level 1," B. Bos, H. Wium Lie, eds., W3C Recommendation 17 Dec 1996, revised 11 Jan 1999. Available at http://www.w3.org/TR/REC-CSS1/.
CSS2: "Cascading Style Sheets, level 2," B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs, eds., W3C Recommendation 12 May 1998. Available at http://www.w3.org/TR/CSS2/.
CSS21: "Cascading Style Sheets, level 2 revision 1," B. Bos, T. Çelik, I. Hickson, H. Wium Lie, eds., W3C Candidate Recommendation 25 February 2004. Available at: http://www.w3.org/TR/CSS21/
CSS3: [CSS 2.1 and CSS 3] Roadmap, CSS WG's table of modules and publication dates.
FLASH: "Flash", Adobe Systems. Available at http://www.adobe.com/devnet/swf.html.
HTML4: "HTML 4.01 Specification," D. Raggett, A. Le Hors, I. Jacobs, eds., W3C Recommendation 24 December 1999. Available at http://www.w3.org/TR/html401/
ISO32000: "Document management - Portable document format - Part 1: PDF 1.7", ISO/TC 171/SC 2. ISO. Available at http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=51502. ISO-approved copy available at: http://www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf.
PDF: "PDF", Adobe Systems. Available at http://www.adobe.com/devnet/pdf.html.
WCAG20: "Web Content Accessibility Guidelines 2.0," B. Caldwell, M Cooper, L Guarino Reid, and G. Vanderheiden, eds., W3 Recommendation 12 December 2008, http://www.w3.org/TR/2008/REC-WCAG20-20081211. The latest version of WCAG 2.0 is available at http://www.w3.org/TR/WCAG20/.
XHTML1: "XHTML 1.0 The Extensible HyperText Markup Language (Second Edition)," S. Pemberton, et al., W3C Recommendation 26 January 2000, revised 1 August 2002. Available at: http://www.w3.org/TR/xhtml1/.

WCAG 2.0 達成方法集

WCAG 2.0 の達成方法と失敗例

W3C ワーキンググループノート 2016 年 10 月 7 日

概要

この文書のステータス

章目次