【重要】 この文書は、W3C ワーキンググループノート Techniques for WCAG 2.0 (原文は英語: 2016 年 10 月 7 日公開) を情報通信アクセス協議会のウェブアクセシビリティ基盤委員会 (WAIC) 翻訳ワーキンググループ (WG4) が翻訳と修正をおこなって公開しているものです。この文書の正式版は、あくまで W3C のサイト内にある英語版であり、この文書には翻訳上の間違い、あるいは不適切な表現が含まれている可能性がありますのでご注意ください。最新で正確な情報は、W3C が公開している原文 (英語) にてご確認ください。

【注意】 達成方法のタイトルが英語のままになっているものは、日本語訳を行っていないため、原文 (英語) にリンクしています。

W3C

WCAG 2.0 達成方法集

WCAG 2.0 の達成方法と不適合事例

W3C ワーキンググループノート 2016 年 10 月 7 日

このバージョン:
https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/
最新バージョン:
https://www.w3.org/TR/WCAG20-TECHS/
前のバージョン:
https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20160317/
編集者:
Michael Cooper, W3C
Andrew Kirkpatrick, Adobe Systems Inc.
Joshue O Connor, InterAccess
過去の編集者:
Loretta Guarino Reid (until May 2013 while at Google, Inc.)
Gregg Vanderheiden (until May 2013 while at Trace R&D Center, University of Wisconsin-Madison)
Ben Caldwell (until September 2010 while at Trace R&D Center, University of Wisconsin-Madison)
Wendy Chisholm (until July 2006 while at W3C)
John Slatin (until June 2006 while at Accessibility Institute, University of Texas at Austin)

この文書は、以下の規定ではないフォーマットでも提供されている:


概要

この文書WCAG 2.0 達成方法集は、ウェブコンテンツ制作者および評価者向けに Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG20] の達成基準を満たすためのガイダンスを提供している。W3C の Web Accessibility Initiative (WAI) が、WCAG 2.0 を補足するために公開している一連の文書の 1 つである。WCAG 2.0 のイントロダクション、補足する技術文書、そして教材については Web Content Accessibility Guidelines (WCAG) Overview を参照のこと。

達成方法は、参考情報である。つまり、達成方法は必須要件ではない。WCAG 2.0 への適合の判断は、WCAG 2.0 の達成基準に基づくものであり、達成方法ではない。 達成方法に関する重要な情報については、WCAG 2.0 解説書の WCAG 達成基準の達成方法を理解するのセクションを参照のこと。

WCAG 2.0 達成方法集は、独立した文書として利用されることを意図したものではない。コンテンツ制作者が通常は How to Meet WCAG 2.0: A customizable quick reference を利用して、WCAGの達成基準を読み、そこから WCAG 2.0 解説書にある具体的なトピックや具体的な達成方法へのリンクを辿ることを想定している。

この文書のステータス

この節では、この文書の発行された時点でのステータスを説明する。他の文書が、この文書にとって代わっている場合もある。現行の W3C の発行文書、及び、この技術レポートの改訂版は、https://www.w3.org/TR/ にある W3C technical reports index で参照可能である。

これは、ワーキンググループノートの WCAG 2.0 達成方法集 である。この達成方法集は、WCAG 2.0 勧告に適合する方法に関するガイダンスを提供するために、Web Content Accessibility Guidelines Working Group によって作成されたものである。各達成方法は、WCAG 2.0 解説書及び How to Meet WCAG 2.0 から参照されている。この文書のコンテンツはガイダンスを提供する参考情報であり、WCAG 2.0 に適合するための要件を定めた規定文書ではないことに留意してほしい。

WCAG 2.0 達成方法集は、ワーキンググループノートとして 2008 年 12 月 11 日に公開されて以来、2010 年 10 月 14 日、2012 年 1 月 3 日、2013 年 9 月 5 日、2014 年 3 月 3 日、2014 年 9 月 16 日、2015 年 2 月 26 日、2016 年 3 月 17 日に更新されてきた。この新しいバージョンは、WCAG 2.0 に対して提供されている参考情報を更新している。なお、WCAG 2.0 自体は変更されておらず、参考情報だけが更新されたことに留意していただきたい。主な変更点には、皆さんや翻訳者からの指摘に基づいた加筆修正である。このバージョンにおける変更点には、G136: 適合していないウェブページの先頭に、適合している代替版へのリンクを提供するARIA2: aria-requiredプロパティによって必須項目を特定する (ARIA) 、F68: 達成基準 4.1.2 の失敗例 - ユーザインタフェース コントロールがプログラム的に解釈される名前(name)を持っていないなどが挙げられる。

変更箇所は、diff-marked version で強調されている。【訳注: 日本語訳の diff-marked version は用意されていない。】

ワーキンググループでは、Instructions for Commenting on WCAG 2.0 Documents で文書化されている選択肢を用いて、コメントを送っていただきたいと考えている。もしそれができない場合は、public-comments-wcag20@w3.org 宛に電子メールで送信することもできる。archives for the public comments list は一般に公開されている。この文書に関して寄せられたコメントは、この文書の将来のバージョン、もしくは、他の方法で対処されるかもしれない。WCAG WG mailing list discussions での議論のアーカイブは一般に公開されており、この文書に関して寄せられたコメントについては、ワーキンググループが将来的に対処することがあるかもしれない。

達成方法を新たに文書化する上で手助けとなる皆さんからの提案を特に歓迎している。達成方法を提案する際には、Techniques Submission Form を使っていただきたい。

この文書は、W3C の Web Accessibility Initiative (WAI) の活動の一環として作成されたものである。WCAG ワーキンググループの目的は、WCAG Working Group charter に記載されている。WCAG ワーキンググループは、WAI Technical Activity の一つである。

ワーキンググループノートとしての公開は、W3C 会員による承認されたものという意味ではない。これはドラフト文書であり、いつでも更新されたり、いつでも他の文書に置き換えられたりすることがある。この文書を、作成作業中のものとして引用すること以外は不適切である。

この文書は、5 February 2004 W3C Patent Policy に則って運営するワーキンググループによって作成された。W3C では、ワーキンググループの成果物に関係する public list of any patent disclosures を管理しており、そのページには特許開示にあたっての指示も含まれている。Essential Claim(s) を含む特許について実際に知識のある人は、section 6 of the W3C Patent Policy に従って、その情報を開示することが求められる。

この文書は、1 September 2015 W3C Process Document に従っている。


章目次



WCAG 2.0 達成方法集のイントロダクション

この文書WCAG 2.0 達成方法集は、ウェブコンテンツ制作者および評価者向けに Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG20] の達成基準を満たすためのガイダンスを提供している。W3C の Web Accessibility Initiative (WAI) が、WCAG 2.0 を補足するために公開している一連の文書の 1 つである。WCAG 2.0 のイントロダクション、補足する技術文書、そして教材については Web Content Accessibility Guidelines (WCAG) Overview を参照のこと。

WCAG 2.0 自身は、変更されることのない安定した文書である。このWCAG 2.0 達成方法集は、現在のベストプラクティス並びに技術及び手段の変化をより多く取り扱うために、およそ1年に2回、定期的に更新する文書である。

達成方法は、参考情報である。つまり、達成方法は必須要件ではない。WCAG 2.0 への適合の判断は、WCAG 2.0 の達成基準に基づくものであり、達成方法ではない。

注記: W3C は、必要とする W3C の十分な達成方法に対して警告する。要求されるべき唯一のものは、WCAG 2.0 の達成基準を満たすことである。より詳しくは、次の文書を参照のこと:

WCAG 2.0 達成方法集は、独立した文書として利用されることを意図したものではない。コンテンツ制作者が通常は How to Meet WCAG 2.0: A customizable quick reference を利用して、WCAGの達成基準を読み、そこから WCAG 2.0 解説書にある具体的なトピックや具体的な達成方法へのリンクを辿ることを想定している。

特定の技術に対する達成方法の公表は、WCAG 2.0 達成基準及び適合性要求を満たすコンテンツを作成するためにすべての状況において使用できることを意味しない。開発者は、特定の技術の限界を認識し、障害をもつ人々にアクセシブルな方法でコンテンツを提供する必要がある。

達成方法に関する重要な情報については、WCAG 2.0 解説書の WCAG 達成基準の達成方法を理解するのセクションを参照のこと。

1. 一般的な達成方法


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

適用(対象)

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

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

解説

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

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

事例

事例 1: オンライン新聞

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

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

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

参考リソース

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

検証

チェックポイント
  1. リンクがそのウェブページ上で最初のフォーカス可能なコントロールである。

  2. リンクのラベルがメインコンテンツへのリンクであることを示している。

  3. リンクが、常に画面に表示されている、又はキーボード・フォーカスを受け取っている際には画面に表示されている。

  4. リンクを有効化することでフォーカスがメインコンテンツに遷移する。

  5. リンクを押下した後、キーボード・フォーカスがメインコンテンツへ移動する。

判定基準
  • 上記のチェック全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

事例

検証

チェックポイント

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

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

  2. その動き又はスクロールが停止し、勝手に再開しない。

  3. 提供されているメカニズムを用いて、コンテンツの動きを再開する。

  4. そのとき、動き又はスクロールが、停止したところから再開する。

判定基準
  • 2. 及び 4. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

事例

  • ある授業のインタラクティブな試験には、1 つのページに全ての問題を載せている。利用者には全ての問題を解き終えるのに必要なだけの時間が与えられている。

  • あるインタラクティブなゲームで、利用者は制限時間内に移動を完了しなければならない代わりに、自分のターン上で好きなだけたくさんの時間がかけられる。

  • あるオンラインオークションで、入札者は時間をずらして複数回の競争入札を提出するのではなく、1 つの値段だけを提出できる。入札は丸一日開かれており、簡単な入札フォームへの入力を完了するのに十分な時間が、誰にでも与えられる。ひとたび入札が閉じられたら、もっともよい値段が勝利する。

参考リソース

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

検証

チェックポイント
  1. 制限時間付きのインタラクションがある(クライアントサイド 及び/または サーバーサイド)。

判定基準
  • 1. を満たしていない。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

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

事例

事例 1

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

事例 2

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

参考リソース

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

検証

チェックポイント
  1. 拡張音声解説のあるバージョンのムービーを開く。

  2. 必要なナレーションを入れる十分な間隔が主音声の発話と発話の間にないとき、拡張音声解説を再生するために映像が一時停止する。

  3. 必要な情報が音声解説で提供されている。

  4. 代替版が別のウェブページにある場合、その別バージョンへのリンクが提供されている。

判定基準
  • 2.、3. 及び 4. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

事例

事例 1

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

事例 2

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

参考リソース

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

検証

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

判定基準
  • 1.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

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

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

事例

検証

チェックポイント
  1. アクセシブルなユーザエージェントを用いてコンテンツを描画する。

  2. ユーザエージェントのアクセシビリティAPIをチェックするアクセシビリティツールを用いて、各ユーザインタフェースコンポーネントを検証する。

  3. 各ユーザインタフェースコンポーネントに対する識別名(name)及び役割(role)が、ツールによって確認できる。

  4. コンポーネントの値を変更する。

  5. アクセシビリティツールにその変更が通知される。

  6. コンポーネントが支援技術で動作する。

判定基準
  • 各ユーザインタフェースコンポーネントにおいて、3, 5, 及び 6 を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G11: 5 秒未満で点滅が終わるようにコンテンツを制作する

適用(対象)

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

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

解説

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

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

事例

検証

チェックポイント
  1. 点滅するアイテムをすべて探す。

  2. 点滅するそれぞれのアイテムは、点滅の始まりから終わりまでの間隔が5秒より短い。

判定基準
  • 2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G13: 状況の変化を引き起こすフォームのコントロールが変化する前に、何が起こるのかを説明する

適用(対象)

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

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

解説

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

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

  • 設定変更によって状況の変化が生じるインタフェース要素よりも音声読み上げ順序が前になるように、ウェブページ上で説明を提供する。

  • 設定変更が状況を変化させるユーザインタフェース要素に到達するために、利用者が特定のステップを完了させなければならないような ステップが複数あるプロセスに対して、状況に変化が起きるステップの前のプロセスで説明を提供する。

  • 設定変更によって状況に変化が生じるユーザインタフェース要素のあるウェブアプリケーションを利用する前に、利用者がトレーニングを受けなければならないようなイントラネットの場合、そのトレーニングの一部として説明が示されている。

事例

  • トップページで、ドイツ語、フランス語とスペイン語という選択肢がラジオボタンで示されている。 ボタンの前には、利用者に対して、選択肢を選ぶことで言語が変更されるという説明が示されている。

  • オンライン調査で 50 問の質問が 1 つずつ表示される。 調査の初めに、利用者が各質問に対して回答を選ぶと次の質問に進むことができるという説明が表示されている。

参考リソース

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

検証

チェックポイント
  • フォーム・コントロールの設定変更により、状況に変化が生じるコンテンツを特定する。

  • コントロールが変更されたとき何が起こるのかについての説明が、コントロール操作の前にある。

判定基準
  • 2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

事例

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

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

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

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

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

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

注記: アスタリスクは、スクリーンリーダー(やその読上げモード)によっては読上げられないことがあり、 またデフォルトの文字サイズよりも小さいサイズで表示されるため、弱視の利用者にとっては見づらいかもしれない。コンテンツ制作者としては、 アスタリスクが用いられていることをテキストで示すとともに、表示されるアスタリスクの文字サイズを大きくすることが重要である。【訳注:日本語の場合は、アスタリスクよりも文字で「必須」と示したほうが、音声読み上げと見た目の両方でより確実である。】

事例 4: 緑色のサブミットボタンのあるフォーム

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

参考リソース

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

検証

チェックポイント

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

  1. 伝えられている情報が、テキストでも示されている。

判定基準
  • 1.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

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

事例

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

参考リソース

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

検証

チェックポイント

コンテンツが一般閃光閾値及び/又は赤色閃光閾値に違反していない。

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

判定基準
  • 1. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G17: テキスト(及び画像化された文字)とその背景の間に、少なくとも 7:1 以上のコントラスト比をもたせる

適用(対象)

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

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

解説

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

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

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

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

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

事例

  • 企業ロゴに合った明るい色の文字を使うことができるように、背景には黒が使用されている。

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

参考リソース

検証

チェックポイント
  1. 以下の公式を用いて、各文字(すべて同一ではない限り)の相対輝度を測る:

    • 色の相対輝度 L = 0.2126 * R + 0.7152 * G + 0.0722 * B と定義されている。この場合のR, G 及び B は:

      • RsRGB <= 0.03928 の場合:R = RsRGB/12.92、それ以外の場合: R = ((RsRGB+0.055)/1.055) ^ 2.4

      • GsRGB <= 0.03928 の場合:G = GsRGB/12.92、それ以外の場合:G = ((GsRGB+0.055)/1.055) ^ 2.4

      • BsRGB <= 0.03928 の場合:B = BsRGB/12.92、それ以外の場合:B = ((BsRGB+0.055)/1.055) ^ 2.4

      注記: また、RsRGB, GsRGB, 及び BsRGBは以下のように定義される:

      • RsRGB = R8bit/255

      • GsRGB = G8bit/255

      • BsRGB = B8bit/255

      注記: "^"記号は指数演算子である。

    注記: エイリアス文字では文字の端から2ピクセルの部分の相対輝度の値を使用する。

  2. 同じ公式を用いて、文字のすぐ隣の背景のピクセルの相対輝度を測る。

  3. 次の公式を用いて、コントラスト比を算出する。

    • (L1 + 0.05) / (L2 + 0.05)

      • L1は前景または背景色の明るい方の相対輝度である。及び、

      • L2は前景または背景色の暗い方の相対輝度である。

  4. コントラスト比が7:1と同じ、又はそれ以上である。【訳注:この計算式を用いているチェックツールで、コントラスト比が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")も見ること。

参考リソース

(今のところ、なし。)

検証

チェックポイント
  1. 以下の公式を用いて、各文字(すべて同一ではない限り)の相対輝度を測る:

    • 色の相対輝度 L = 0.2126 * R + 0.7152 * G + 0.0722 * B と定義されている。この場合のR, G 及び B は:

      • RsRGB <= 0.03928 の場合:R = RsRGB/12.92、それ以外の場合: R = ((RsRGB+0.055)/1.055) ^ 2.4

      • GsRGB <= 0.03928 の場合:G = GsRGB/12.92、それ以外の場合:G = ((GsRGB+0.055)/1.055) ^ 2.4

      • BsRGB <= 0.03928 の場合:B = BsRGB/12.92、それ以外の場合:B = ((BsRGB+0.055)/1.055) ^ 2.4

      注記: また、RsRGB, GsRGB, 及び BsRGBは以下のように定義される:

      • RsRGB = R8bit/255

      • GsRGB = G8bit/255

      • BsRGB = B8bit/255

      注記: "^"記号は指数演算子である。

    注記: エイリアス文字では文字の端から2ピクセルの部分の相対輝度の値を使用する。

  2. 同じ公式を用いて、文字のすぐ隣の背景のピクセルの相対輝度を測る。

  3. 次の公式を用いて、コントラスト比を算出する。

    • (L1 + 0.05) / (L2 + 0.05)

      • L1は前景または背景色の明るい方の相対輝度である。及び、

      • L2は前景または背景色の暗い方の相対輝度である。

  4. コントラスト比が4.5:1と同じ、又はそれ以上である。【訳注:この計算式を用いているチェックツールで、コントラスト比が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 回しか光らないように設計されている。

参考リソース

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

検証

チェックポイント
  1. どの1秒間においても3回よりも多い閃光がない。

  2. 3回の閃光がある場合、1秒間の最後の明/暗の状態が初めと同じである。

判定基準
  • 1.及び2.の両方を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G21: 利用者がコンテンツ内に閉じ込められないようにする

適用(対象)

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

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

解説

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

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

  • コンテンツ内でフォーカスを前進させるためのキーボード機能(一般的にはTabキー)によって最後のナビゲーション位置に到達した後、コンテンツのサブセットから抜け出せるようにする。

  • コンテンツのサブセットからフォーカスを出すキーボード機能を提供する。サブセット内でアクセシブルな方法によってその機能を必ず明記する。

  • コンテンツのサブセットで用いられているウェブコンテンツ技術が自然に「親コンテンツに戻る」ためのキーボードコマンドを提供している場合、利用者がそのプラグインに入る前に、そのコマンドを明記して利用者がどのように再びプラグインの外に出られるかを分かるようにする。

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

事例

  • いったん利用者がタブ移動でアプレットの中に入ると、それ以降のタブ移動はアプレットによって処理され、その利用者がタブ移動で外に出られないようになっている。しかしながら、そのアプレットは、アプレット内で連続したタブ移動を終えた時、キーボードフォーカスが親ウィンドウに戻るように作られている。

  • アクセシビリティ・サポーテッドではないコンテンツを含んでいるページには、キーボードによってアクセシビリティ・サポーテッドなコンテンツにフォーカスを戻す方法についての説明がある。その説明は、アクセシビリティ・サポーテッドではないコンテンツより前に書かれている。

  • アクセシビリティ・サポーテッドではないコンテンツから入手可能なヘルプ情報は、キーボード操作によってアクセシビリティ・サポーテッドなコンテンツへフォーカスを戻す方法を説明しており、そのヘルプ情報はキーボードによるアクセスが可能である。

  • ウェブページで入手可能なヘルプ情報は、キーボード操作によってアクセシビリティ・サポーテッドではないコンテンツからアクセシビリティ・サポーテッドなコンテンツへフォーカスを戻す方法を説明しており、そのヘルプ情報はキーボードによるアクセスが可能である。

参考リソース

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

(今のところ、なし。)

検証

チェックポイント
  1. Tabキーでコンテンツ内を最初から最後まで移動する。

  2. キーボードフォーカスがどのコンテンツにも閉じ込められていない。

  3. キーボードフォーカスがコンテンツに閉じ込められてしまう場合、コンテンツから抜け出す方法を説明したヘルプが利用でき、キーボード操作でアクセスできる。

判定基準
  • 2.が該当しない。【訳注:「2.または3.のいずれかを満たしている」となるのが正しいと思われる】

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

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

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

解説

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

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

事例

事例 1

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

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

事例 2

ウェブページに「最初の移住者はメイフラワー号に乗ってアメリカにきた。」という文章がある。

事例 3

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

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

参考リソース

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

検証

チェックポイント

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

  1. そのリンクが文の一部である。

  2. そのリンクテキストと文を組み合わせると、リンクの目的が説明されている。

判定基準
  • 上記全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

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

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

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

事例

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

参考リソース

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

  • 手話を作成するための指針

    • "Sign Language presentation"では、手話通訳者を撮影する際の留意点の概要を知ることができる。元の素材が書き言葉の場合と話し言葉の場合の両方についての議論も含まれている。

    • 撮影のテクニックについては chapter 12, “Filming the Signer(s)" で考察されている。

    • オリジナルの同期したメディアコンテンツに関連して手話通訳を表示させる方法についての有益な情報は Chapter 13, "Editing"で提供されている。

      注記: これらの実装方法はウェブベースのプレゼンテーションにも適用される必要がある。

検証

チェックポイント
  1. 耳が聞こえて、使用されている手話に精通した人に映像を見せる。

  2. 手話通訳が画面上に表示されている。

  3. 会話と重要な音が、画面に映っている手話通訳によって伝達されている。

判定基準
  • 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. リンクがそのアイテムの定義にリンクしている。

判定基準
  • 1.及び 2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

事例

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

事例 2: 事例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."【訳注:音声が英語なので、和訳していません。】

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

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

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

参考リソース

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

検証

チェックポイント
  1. 前景音声が流れている間で、背景音声が大きい部分を特定する。

  2. デシベル(A特性)音圧レベルの値を計測する。

  3. 前景音声のデシベル(A特性)音圧レベルの値を計測する。

  4. 前景音声の値から背景音声の値を引き算する。

  5. 差が20デシベル以上ある。

判定基準
  • 5. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

この達成方法の目的は、支援技術に提示されたコンテンツの順序によって、利用者がコンテンツを理解できるようにすることである。いくつかの達成方法では、例えコンテンツのもともとの順序がわかりにくいとしても、コンテンツを視覚的に意味のある順序で表現することができる。【訳注:原文の意味が不明確なため、WCAGワーキンググループに確認中です。】

例えば、HTMLに表記方向が異なる言語を混在させる際、双方向アルゴリズム(文字に応じて適切な書字方向に表示するアルゴリズム)によって、句読点が間違った場所に置かれてしまう恐れがある。正しい順序で並べられているコンテンツは、コンテンツの流れにおける正しい順序で句読点を保持したまま、双方向アルゴリズムを上書きするためにマークアップを用いている。つまり、デフォルトのレンダリングで句読点が正しく配置されるように、コンテンツの流れの中で句読点を別の場所に移動させたりしていない。【訳注:原文の意味が不明確なため、WCAGワーキンググループに確認中です。】

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

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

事例

事例 1

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

コード例:


マークアップ:

<h1>美術館のページ</h1>
<ul id="nav">
	<li><a href="#">リンク 1</a></li>

	...
	<li><a href="#">リンク 10</a></li>
</ul>
<div id="description">
<h2>モナリザ</h2>
<p>

<img src="img.png" alt="モナリザ">
</p>
<p>...絵の詳しい説明...</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;
} 

参考リソース

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

検証

チェックポイント
  1. (例 レイアウトスタイルを削除する、又はリニアライズするツールを用いるなど、)ウェブコンテンツ技術の標準的アプローチを使用し、コンテンツをリニアライズ(線形化)する。

  2. リニアライズした順序で並べたコンテンツが、リニアライズする前のコンテンツと同じ意味を示している。

判定基準
  • 2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G58: 非テキストコンテンツのすぐ隣に、時間の経過に伴って変化するメディアの代替へのリンクを置く

適用(対象)

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

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

解説

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

事例

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

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

コード例:

<a name="Olympic_Wrestling"></a>
<p><a href="http://www.example.com/movies/olympic_wrestling.mov">オリンピックレスリング動画</a>, 
<a href="http://www.example.com/transcripts/olympic_wrestling_transcript.htm>オリンピックレスリングの照合されたトランスクリプト
</a></p>
事例 2: 事例2:HTMLドキュメント内の.MOVドキュメントへ戻る

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

コード例:

<p>スポーツアナウンサー 1:これは、イングランドのウィルジョンソンと
アルゼンチンのセオドル・デリンゴの今夜の最高の戦いです。</p>

<p>情景:スタンド内に500人の観衆が詰め掛けたスタジアムの中央に
マットが設置されています。</p>

<p> ...更なる発話 ...<p>

<p> ...更なる情景...</p>

<p> ...その他...</p>

<p>スポーツアナウンサー  2:今夜はこれで最後となります。
ウィル・ジョンソンが新たなゴールドメダリストになったこの場所から、
今夜もお付き合い頂きありがとうございました。 
<a href="../movies/Olympic_Sports.htm#Olympic_Wrestling>動画ページへ戻る</a> </p>

参考リソース

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

検証

チェックポイント
  1. リンクが非テキストコンテンツの直前又は、直後にある。

  2. そのリンクがこの同期したメディアの照合ドキュメントへ直接遷移する有効なリンクである。

  3. その同期したメディアコンテンツの元の場所へ利用者が戻るためのリンク又は、復帰機能が利用可能である。

判定基準
  • 1.から3.の全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

事例

  • フォーム内に、順番に入力すべき2つのテキスト入力フィールドがある。1 つめのテキスト入力フィールドはコンテンツ内で 1 番目に置かれ、2 つめのテキスト入力フィールドは2番目に置かれている。

  • フォーム内に、2 つの情報セクションが隣り合わせに表示されている。片方のセクションには、申込者についての情報が含まれていて、もう片方のセクションには、申込者の配偶者についての情報が含まれている。申込者のセクションにある全てのインタラクティブな要素は、配偶者のセクションにあるどの要素よりも前に、フォーカスを受けるようになっている。そして、各セクション内の要素は、そのセクションを読む順番に従ってフォーカスを受けるようになっている。

参考リソース

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

検証

チェックポイント
  1. コンテンツ内のインタラクティブな要素の順序を確認する

  2. インタラクティブな要素の論理的な順序を確認する。

  3. コンテンツ内のインタラクティブな要素の順序が、その論理的な順序と一致している。

判定基準
  • 3. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

事例

  • 事例 1: ウェブページを開くと、トランペットのファンファーレが鳴り、静かになる。

  • 事例 2: ウェブページを開くと、「品質がビジネスでは一番重要です」という社長の声が聞こえ、静かになる。

  • 事例 3: 「エンターキーを押して始めてください」という始め方の操作説明が流れる。

  • 事例 4: ウェブページを開くと警告音が鳴り、静かになる。

参考リソース

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

検証

チェックポイント
  1. ウェブページをロードする。

  2. 自動的に再生される全ての音が3秒又はそれより早く停止される。

判定基準
  • 2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

事例

  • あるウェブサイトでは各ページの先頭に、ロゴ、タイトル、検索フォーム、ナビゲーションバーが置かれている。これらは同じ相対的順序で提示される。あるページには検索フォームがないが、その他のコンポーネントは繰り返し現れるどのページにおいてもやはり同じ順序で提示される。

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

参考リソース

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

検証

チェックポイント
  1. ウェブページの集合(たとえば一つのウェブサイト)中の全てのページで繰り返し提示されるコンポーネントをリストアップする。

  2. それぞれのコンポーネントにおいて、そのコンポーネントが現れる全てのウェブページで他の繰り返し出現するコンポーネントとの相対的位置関係が一貫している。

  3. それぞれのナビゲーションのためのコンポーネントにおいて、そこに含まれるリンクやプログラム的な参照が必ず同じ相対的順序で提示される。

判定基準
  • 2.及び 3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G62: 用語集を提供する

適用(対象)

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

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

解説

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

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

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

事例

事例 1

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

事例 2

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

事例 3

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

事例 4: Example 4

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

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

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

参考リソース

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

検証

チェックポイント
  1. 次のいづれかである

    • 用語集がウェブページで提供されている、又は

    • 用語集を見つけるメカニズムが利用できる。

  2. 定義されるべき個々の単語、語句、又は略語が用語集で定義されている。

  3. 用語集には個々の専門用語に対して一つの定義のみ提供されている。

判定基準
  • 上記の 3 つを全て満たしている。

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

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

  • サイト全体の概要を提供する。

  • 利用者が、サイトが何を含んでいて、コンテンツがどのように構成されているか、理解するのを助ける。

  • サイトのいろいろな部分によって異なる、複雑なナビゲーションバーの代替物を提供する。

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

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

  1. サイトの全ての区分にリンクしていない、又は

  2. サイトの構成とは異なる構成を提供する、又は

  3. もはや有効ではないリンクを含む

事例

事例 1

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

事例 2

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

参考リソース

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

検証

チェックポイント
  1. サイトにサイトマップがある。

  2. サイトマップにあるリンクが、サイトの該当する区分に通じている。

  3. サイトマップにある各リンクについて、対象のページにサイトマップへのリンクがある。

  4. サイトの各ページについて、サイトマップから始まるリンクの組み合わせを辿ることでページに辿りつくことができる。

判定基準
  • 上記、全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G64: 目次を提供する

適用(対象)

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

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

解説

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

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

  • ドキュメントの内容と構成の概要を利用者に与える。

  • 読者がオンラインドキュメントの特定の区分に直接行けるようにする。

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

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

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

事例

事例 1

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

事例 2

参考リソース

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

検証

チェックポイント
  1. 目次、又は目次へのリンクがドキュメントに存在する。

  2. 目次の見出しの文言及び順序が、ドキュメントのセクションの名前(見出しの文言)及び順序と一致する。

  3. 目次の各見出しが、ドキュメントの各セクションにリンクしている。

判定基準
  • 上記の全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

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

事例

事例 1

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

コード例:

ホーム :: デベロッパーセンター :: 手引き

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

事例 2

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

コード例:

ホーム / ギャラリー / 南極大陸 / ペンギン / ジェンツーペンギン

「ジェンツーペンギン」を除くすべての項目がリンクとして実装されている。現在位置(ジェンツーペンギン)はパンくずリストに含まれているが、リンクとしては実装されていない。

事例 3

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

現在位置: Acme Company → 電化製品 → コンピューター → ノートパソコン

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

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

この例に対するHTML

コード例:

 
          <nav aria-label="Breadcrumbs"> 
            <h2>現在位置:</h2> 
            <ul>
              <li><a href="/">Acme Company</a> &#8594;</li> 
              <li><a href="/electronics/">電化製品</a> &#8594;</li>
              <li><a href="/electronics/computers/">コンピューター</a> &#8594;</li>
              <li>ノートパソコン</li>
            </ul> 
          </nav>
      

この例に対するCSS

コード例:

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

実装例: Breadcrumb example

参考リソース

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

検証

チェックポイント

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

  1. あるウェブページに移動する。

  2. パンくずリストが表示されている。

  3. パンくずリストが、現在位置に達する正しい案内の順序、又はサイト構造において現在位置までの正しい階層の経路を表示している。

  4. 現在位置を含んでいないパンくずリストに:

    1. パンくずリストのすべての要素がリンクとして実装されている。

  5. 現在位置を含んでいるパンくずリストに:

    1. 現在位置を除くすべての要素がリンクとして実行されている。

    2. 現在位置がリンクとして実装されていない。

  6. すべてのリンクが、パンくずリストによって指定された正しいウェブページへ移動する。

判定基準
  • パンくずリストを使用している一連のすべてのウェブページについて:

    • 2.、3.、及び 6.を満たしている。

    • その上で、4.又は 5.のいずれかを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

事例

事例 1
  • 東海岸ハイウェイを映したライブ映像のフィードに、「東海岸ハイウェイI-81号線インターチェンジ南側のライブ映像で、現在の道路状況を放映中」とその内容を説明したラベルが付けられている。

  • ミシシッピ州議会のライブ音声フィードに、「ミシシッピ州議事堂内のマイクロフォンからのライブ音声」と、その内容を説明したラベルが付けられている。

参考リソース

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

検証

チェックポイント
  1. 非テキストコンテンツを取り除くか、非表示にするか、又は覆い隠す。

  2. 簡潔な代替テキストを表示させる。

  3. コンテンツそのものはなかったとしても、非テキストコンテンツの目的が明らかである。

判定基準
  • 3. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G69: 時間の経過の伴い変化するメディアに対して代替コンテンツを提供する

適用(対象)

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

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

解説

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

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

  • 発話(会話)

  • 音(自然な音または人工的な音)

  • 場面や背景

  • 人や動物などの行動及び表情

  • テキスト又はグラフィック

  • その他

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

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

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

事例

  • 新しい機器の使い方を従業員に示す研修フィルムで、1 人の人が使い方を実演しながら、同時に説明している。この研修フィルムを制作した際に使った脚本が代替コンテンツの元素材として使用されていて、実際の発話内容などに合わせて編集・変更されている。研修ビデオと、時間の経過に伴って変化するメディアの代替コンテンツは、この会社のウェブサイトで公開されている。従業員は、機器の使い方を学ぶにあたって、このどちらか一方、あるいは両方を使うことができる。

  • インタラクティブなショッピング環境で、利用者がバーチャル店舗を操作して買い物できるようになっている。時間の経過に伴って変化するメディアの代替コンテンツでは、利用者がバーチャルショッピングカートに品物をドラッグするのではなく、リンクを含むテキストで提供された同じショッピングのコンテンツにアクセスして、商品陳列棚の列を選び、商品を購入できるようになっている。

参考リソース

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

検証

チェックポイント
  1. 時間の経過に伴って変化するメディアに対する代替コンテンツを参照しながら、同期したメディアによるプレゼンテーションを閲覧する

  2. 時間の経過に伴って変化するメディアに対する代替コンテンツにある発話内容が、同期したメディアによるプレゼンテーションでの発話内容と一致している。

  3. 時間の経過に伴って変化するメディアに対する代替コンテンツに、音の説明がある。

  4. 時間の経過に伴って変化するメディアに対する代替コンテンツに、場面及び場面の変更の説明がある。

  5. 時間の経過に伴って変化するメディアに対する代替コンテンツに、あらゆる"登場人物"(人、動物など)の行動及び表情の説明がある。

  6. 代替コンテンツが別のページにある場合、その代替コンテンツへのリンクが提供されている。

判定基準
  • 2.、3.、4. 及び 5. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

事例

事例 1

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

事例 2

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

参考リソース

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

検証

チェックポイント

定義が必要な語句や略語について:

  1. その語句や略語をオンライン辞書で検索するメカニズムがウェブページにある。

  2. その語句や略語の検索結果として表示される内容が、正しい定義である。

判定基準
  • 1. 及び 2. を満たしている。

注記:WCAGで用いている略語の定義は、「単語、語句、又は名称の短縮形で、その略語が言語の一部になっていないもの。 」である。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

事例

事例 1

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

コード例:


      <form action="test.html">
	<label for="test">テストコントロール
	<a href="help.html" target="_blank">ヘルプ</a></label>
	<input type="text" name="test" id="test" />
</form>

検証

チェックポイント
  1. フォームが含まれるウェブページを特定する。

  2. そのページ内に、このウェブページ又は、その他のリソース内に含まれる、フォームの全ての項目を入力するためのヘルプ情報へのリンクが一つ以上提供されている。

  3. インタラクティブなコントロールのすぐ前、又は後ろに、そのコントロールのためのヘルプ情報へのリンクがある。

判定基準
  • 2.又は3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

この達成方法の目的は、長い説明文を直接組み込む機能(例: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: 音声しか含まないファイルのトランスクリプト

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

参考リソース

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

検証

チェックポイント
  1. 非テキストコンテンツの直前又は直後にリンクがある。

  2. 非テキストコンテンツの長い説明文を直接指し示す有効なリンクとなっている。

  3. 長い説明文が非テキストコンテンツと同じ情報を伝達している。

  4. 利用者が非テキストコンテンツのある元の場所に戻れるようにするためのリンク又は「戻る」機能が利用可能である。

判定基準

上記の4つ全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

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

事例

事例 1: 棒グラフ

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

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

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

参考リソース

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

検証

チェックポイント
  1. 簡潔な代替テキストに長い説明文の場所が含まれている。

  2. 長い説明文が視覚的な配置順及び音声読み上げ順序でも非テキストコンテンツの近くにある。

  3. 長い説明文が非テキストコンテンツと同じ情報を伝達している。

判定基準

上記の3つ全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

自動更新するコンテンツ

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

解説

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

事例

検証

チェックポイント
  1. 自動更新するコンテンツが含まれるページを見つける。

  2. 自動更新に対して、自動更新のタイミングを調整するメカニズムがある。

  3. 自動更新が初期状態では無効になっている、又は自動更新される前に警告し利用者が停止できる。

判定基準
  • 3. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

事例

事例 1

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

コード例:

<a href="news.jsp">このページを更新する</a>
事例 2

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

参考リソース

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

検証

チェックポイント
  1. コンテンツを更新するメカニズムを見つける(もしそのようなメカニズムが存在しているならば)。

  2. メカニズムそれぞれについて、利用者が更新を要求できるようになっている。

  3. メカニズムによって自動更新が実行されうる。

判定基準
  • 2. を満たしていて、3. に該当しない。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

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

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

事例

  • 北東部地域の旅行ビデオで、会話の合間に追加された音声ガイドがあり、全盲の利用者が登場人物の話していることを随時理解できるようになっている。

  • キツツキが木をつついて巣を作る様子を示したビデオがある。利用者がコンテンツ内のボタンを押すと、音声ガイドを提供するトラックのオン/オフが切り替えられるようになっている。

  • 講義のビデオで、講師が「これが最も重要です」などの表現をした個所すべてに、音声ガイドが付加されている。この音声ガイドにより、ビデオを見ることができず聞くだけの利用者にも、「これ」が何を指すのかが分かるようになっている。

  • 映画のファイルに2つの音声トラックがあり、片方に音声ガイドが含まれている。利用者は、メディアプレーヤーでトラックを選択することにより、この映画を観賞する際の音声トラックを選ぶことができる。

参考リソース

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

検証

チェックポイント
  1. 例えばコンテンツ自体にあるコントロールによって、又はメディアプレーヤーやOSでの設定によって、音声解説を含む音声トラックを作動させる機能がある。

  2. 同期したメディアの音声を聞く。

  3. 発話の合間を使って、視覚的に伝えているコンテンツの重要な情報が伝えられている。

判定基準
  • 1. 及び 3. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

  • 短いテキスト及び静的なテキストコンテンツの音声バージョン

    この方法は、量の少ないテキストや、めったに変更しない文書に効果的である。

    1. 誰かがテキストを読み上げたものを録音するか、又は個々の文書や一部の段落を合成音声に変換するツールを利用する。できれば、最も聞き取りやすく、魅力的な声を採用するのがよい。

    2. 音声バージョンを音声ファイルとして保存する。その際、広く利用されていて、多くのメディアプレーヤーがサポートしている音声フォーマットを用いる。

    3. 音声バージョンへのリンクを提供する。

    4. 音声フォーマットを明記する(例えば、.MP3、.WAV、.AUなど)。

    5. そのフォーマットをサポートしているメディアプレーヤーへのリンクを提供する。

  • よく変更するテキストの音声バージョン

    ページをよく変更する場合や、利用者の選択によってテキストコンテンツが変わる場合は、サーバサイドで処理する方法が最もよいだろう。サーバサイドで処理するツールの中には、利用者が興味のあるテキストを選択し、聞くことができるものがある。通常は、利用者がテキストから音声への変換を開始するボタンを押せば読み上げられる。

事例

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

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

参考リソース

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

(今のところ、なし。)

検証

チェックポイント
  1. コンテンツの音声バージョンが利用できる。

判定基準
  • 1. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G80: 状況の変化を開始する実行ボタンを提供する

適用(対象)

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

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

解説

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

事例

事例 1

状況の変化が起こるフォームで送信ボタンが使用されている。

参考リソース

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

検証

チェックポイント
  1. コンテンツの中から全てのフォームを見つけ出す。

  2. それぞれのフォームに送信ボタンがある。

判定基準
  • 2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

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

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

事例

事例 1

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

参考リソース

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

  • Guidelines for the Production of Signing Books

    • "Sign Language presentation" gives a broad overview of issues to consider when filming sign language interpreters. Includes discussion of signing both written and spoken originals.

    • Techniques for filming are discussed in chapter 12, “Filming the Signer(s)".

    • Useful information about how to display the sign language interpreter in relation to the original synchronized media content is provided in Chapter 13, "Editing".

      注記: These techniques may need to be adapted for Web-based presentation.

検証

チェックポイント
  1. プレーヤーで手話ウィンドウを表示させる。

  2. 耳が聞こえて、使用されている手話に精通した人にプログラムを見せる。

  3. 手話通訳が画面上又は別ウィンドウに表示されている。

  4. 会話と重要な音が手話通訳によって伝達され、音に同期している。

判定基準
  • 3.及び 4.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

事例

事例 1
  • 目と手のコーディネーションスキルを開発するためのアプレットに、「マウスと動く標的を使用して目と手の連動スキルを開発するアプレット」という代替テキストが付けられている。

  • 丸いディスクの端を押してリモートカメラを制御し、真ん中のスライダーを使ってズームを調整するカメラのアプレットに、「リモートビデオカメラの照準とズームのコントロール」という代替テキストが付けられている。

参考リソース

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

検証

チェックポイント
  1. 非テキストコンテンツを取り除く、非表示にする、又は覆い隠す。

  2. 非テキストコンテンツを代替テキストに置き換える。

  3. 非テキストコンテンツそのものはなかったとしても、代替テキストによって同じ情報が得られる。

判定基準
  • 3. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

事例

検証

チェックポイント
  1. 一つ又は複数の必須項目への入力を故意にせず、フォームを記入してから送信する。

  2. 未入力のままになっている必須項目を特定する説明がテキストで提供される。

  3. そのデータが再表示されることが適切ではない、セキュリティに関連するフィールド(例:パスワード)にない限り、利用者によって入力済みのデータが再表示される。

判定基準
  • 2.及び3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G84: 利用者が認められた値以外の情報を提供した際に、テキストの説明文を提供する

適用(対象)

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

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

解説

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

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

事例

検証

チェックポイント
  1. フォーム項目に無効なデータを入力する。

  2. エラーに関する情報がテキストで提供される。

判定基準
  • 2. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G85: 利用者の入力が要求されたフォーマット又は値ではなかった際に、テキストの説明文を提供する

適用(対象)

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

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

解説

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

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

  • その項目における正しいデータ入力の例を示す

  • その項目における正しいデータ入力を説明する

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

事例

検証

チェックポイント
  1. 要求されているフォーマット又は値ではない入力を故意に行う。

  2. エラーになった項目を特定して、無効な入力の内容及びその修正方法に関する情報を提供する説明文がテキストで提供される。

  3. そのデータが再表示されることが適切ではない、セキュリティに関連するフィールド(例: パスワード)にない限り、利用者によって入力済みのデータが再表示される。

判定基準
  • 2. 及び3. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G86: 前期中等教育レベルを超えた読解力を必要としないテキストで要約を提供する

適用(対象)

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

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

解説

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

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

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

  1. コンテンツの中で最も重要なアイデアと情報を見出す。

  2. それと同じアイデアと情報を表現すべく、より短い文章で、一般的な言葉を用いて、1つまたはそれ以上のパラグラフを書く(パラグラフの数は、元の文章の長さによる)。

  3. 要約の読みやすさを評価する。

  4. 要約を編集する。長い文章を2つに分けたり、長い単語やなじみのない言葉はより短く一般的な用語に置き換えることを検討する。

  5. 必要であれば、3 と 4 を繰り返す。

事例

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

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

参考リソース

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

検証

チェックポイント

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

  1. その要約の読みやすさを評価する。

  2. その要約が前期中等教育レベルを超えた読解力を必要としていない。

判定基準
  • 2. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

事例

事例 1

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

事例 2

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

事例 3

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

事例 4

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

参考リソース

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

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

SMIL

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

検証

チェックポイント
  1. メディアプレーヤーのクロ―ズドキャプション機能をオンにする。

  2. 同期したメディアのコンテンツを見る。

  3. (発話内容及び音の伝えている情報全ての)キャプションが表示されている。

判定基準
  • 3. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G88: ウェブページに対して、コンテンツの内容が分かるページタイトルを提供する

適用(対象)

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

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

解説

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

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

  • そのウェブページの主題を特定している。

  • 例えば、スクリーンリーダーで読み上げている場合、又はサイトマップや検索結果一覧にある場合など、前後の文脈がなくても意味がわかるようになっている。

  • 簡潔である。

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

  • どのサイト又は他のどのリソースに属しているかを特定している。

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

事例

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

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

コード例:

<title>求人情報:グループ名:組織名</title>
事例 2: 例2:コンテンツの内容が分かるページタイトルの付いた同期したメディアによるプレゼンテーション

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

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

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

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

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

参考リソース

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

検証

チェックポイント
  1. ウェブページにページタイトルがある。

  2. そのページタイトルが、ウェブページのコンテンツに関連している。

  3. そのページタイトルによって、ウェブページを特定できる。

判定基準
  • 上記全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G89: 所定のデータ書式及び入力例を提供する

適用(対象)

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

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

解説

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

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

事例

事例 1: 事例1

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

コード例:

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

検証

チェックポイント
  1. 所定の書式でしか利用者の入力データを受け付けないフォーム・コントロールを特定する。

  2. 1.で特定した各フォーム・コントロールが、求めている書式情報を提供している。

判定基準
  • 2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

事例

  • 事例 1: ドラッグアンドドロップ機能  写真のアプリケーションに、スライドショーのような表示のためにオンラインアルバム内で写真を並び替えることができるように「ドラッグ」及び「ドロップ」の機能がある。また、利用者がキーボードのみを用いて写真を選び、リスト内の適切な場所でアイテムを「切り取り」、「貼り付け」できる機能もある。

  • 事例 2: 並び替え機能  質問事項をドラッグで動かして調査票を作ることができるウェブアプリケーションには、テキストフィールドの付いた質問リストがあり、利用者が質問番号を入力することによって、必要に応じて質問事項を並び替えることができる。

参考リソース

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

検証

チェックポイント
  1. すべての機能がキーボードだけを使ってアクセスできる。

判定基準
  • 1.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

事例

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

コード例:

<a href="routes.html">
  ボルダーズ・クライミング・ジムの現在のルート
</a>

参考リソース

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

検証

チェックポイント

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

  1. リンクテキストがそのリンクの目的を説明している。

判定基準
  • 1.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

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

  • なぜこの非テキストコンテンツがここにあるのか?

  • どんな情報が提示されているのか?

  • どんな目的を果たしているのか?

  • もし非テキストコンテンツを使うことができないとき、同じ機能又は情報を伝えるためにどのような言葉を使えばよいか?

事例

事例 1: Example 1

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

事例 2: Example 2

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

参考リソース

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

検証

チェックポイント
  1. 非テキストコンテンツを取り除くか、非表示にするか、覆い隠す。

  2. 長い説明を表示する。

  3. 長い説明が非テキストコンテンツによって伝えられた情報と同じ情報を伝えている。

判定基準
  • 3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G93: オープン・キャプション(常に表示)を提供する

適用(対象)

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

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

解説

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

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

事例

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

  • 報道機関が、全てのコンテンツにオープンキャプションを提供している。

参考リソース

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

検証

チェックポイント
  1. クローズドキャプションをオフにした状態で同期したメディアを見る。

  2. (発話内容及び重要な音の伝えている情報全ての)キャプションが表示されている。

判定基準
  • 2. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

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

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

  • なぜこの非テキストコンテンツがここにあるのか?

  • それはどのような情報を示しているのか?

  • それはどのような目的を果たすのか?

  • 非テキストコンテンツを使用することができない場合、何という言葉を使って同じ機能及び(又は)情報を伝達するか?

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

事例

  • 検索ボタンが拡大鏡の画像を使っている。その代替テキストには「拡大鏡」ではなく、「検索」と書かれている

  • ロープに結び目が作られていく様子を矢印で示して、結び目がどのような結び方になっているかを絵で説明している。その代替テキストは結び方を説明すべきで、その絵が何に見えるかではない。

  • おもちゃを正面から見た絵がある。その代替テキストはおもちゃの正面から見た様子を説明している。

  • タイヤの交換方法をアニメーションで示している。簡潔な代替テキストはそのアニメーションが何についてであるかを説明している。長い代替テキストはタイヤの交換方法を説明している。

  • TechTron 社のロゴがリスト中のそれぞれの製品の隣にあり、「TechTron」という簡潔な代替テキストにより製造元を示している。

  • 10 月の売上げを示しているグラフには「10 月の売上表」という簡潔な代替テキストがある。 併せてそのグラフの全ての情報を提供する長い説明もある。

  • 図案化された文字の「戦争の歴史」という言葉を埋め込んだ画像が見出しにある。その画像に対する代替テキストは「戦争の歴史」である。

  • 棚の上に並んだ本の画像にはその本に関するウェブページへのナビゲーション手段を提供するインタラクティブなエリアがある。 「この区画で購入できる本。本を選択するとその本の詳細がわかります。」という代替テキストは画像及びインタラクティブな性質を説明している。

参考リソース

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

検証

チェックポイント
  1. 非テキストコンテンツを削除する、非表示にする、又は隠す。

  2. 代替テキストで置き換えてみる。

  3. 何も情報が失われていない(非テキストコンテンツの目的が代替テキストと一致している)。

  4. 非テキストコンテンツがコンテンツを理解する上で重要な文字情報を含んでいるならば、その文字を代替テキストに含める。

判定基準
  • 3.を満たしている。非テキストコンテンツにコンテンツを理解するために必要な文字情報が含まれているならば、4.も満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

  • なぜこの非テキストコンテンツがここにあるのか?

  • それはどのような情報を示しているのか?

  • それはどのような目的を果たすのか?

  • 非テキストコンテンツを使用することができない場合、何という言葉を使って同じ機能及び(又は)情報を伝達するか?

事例

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

参考リソース

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

検証

チェックポイント
  1. 非テキストコンテンツの簡潔な説明を提供している簡単な代替テキストがある。

判定基準
  • 1.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G96: 理解すべき情報を感覚的にだけ伝えることのないように、テキストでもアイテムを特定する

適用(対象)

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

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

解説

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

事例

事例 1: 事例1

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

事例 2: 事例2

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

事例 3: 事例3

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

コード例:

<table>
  <tbody>
    <tr>
      <td colspan="2">右下の「前へ戻る」ボタンを押して下さい。</td>
      <td>
        <span style="background: ButtonFace; color: ButtonText; border: 
        medium outset ButtonShadow; 
        width: 5em; display: block; font-weight: bold; text-align: center;">
        印刷</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;">
        中止</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;">
        前へ戻る</span>
      </td>
    </tr>
  </tbody>
</table>

参考リソース

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

(今のところ、なし。)

検証

チェックポイント

ウェブページ内において、オブジェクトの形、大きさ、又は位置を使って説明しているすべての言及箇所を探し出す。そのような各アイテムにおいて:

  1. その言及箇所には、形や大きさ、又は相対的な位置についての情報がない場合でもアイテムを見つけて、特定するための追加情報が含まれている。

判定基準
  • 1.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

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

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

事例

事例 1

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

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

参考リソース

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

検証

チェックポイント

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

  1. その略語の最初の使用箇所を探す。

  2. 最初の使用箇所の直前又は直後に、略語の元の語がある。

  3. その元の語が、略語の使用として正しい元の語である。

判定基準
  • 2. 及び 3. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

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

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

事例

検証

チェックポイント

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

  1. 利用者に入力内容を確認するように促している。

  2. 利用者のデータが複数のステップで収集される場合、利用者が前のステップに戻ってデータを見直したり変更したりできる。

  3. トランザクションが確定する前に、利用者が入力した全てのデータの一覧が提供され、必要に応じて間違えを修正できる方法が提供されている。

判定基準
  • 2. 又は 3. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G99: 消去した情報を元に戻せるようにする

適用(対象)

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

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

解説

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

事例

検証

チェックポイント
  1. コンテンツを削除する機能を特定する。

  2. コンテンツを削除して、復元してみる。

  3. 削除された情報が復元されている。

判定基準
  • 3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G100: 非テキストコンテンツの一般に認められた名前又は内容が分かる名前となる簡潔な代替テキストを提供する

適用(対象)

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

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

解説

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

事例

事例 1
  • モナリザの絵には「モナリザ。レオナルド・ダ・ビンチ作」という代替テキスト がある。

  • 音声ファイルには「テルミンを演奏している5人の小学生」という代替テキストがある。

  • 有名なモダンアートの作品には「赤、青、及び黄色。ピエト モンドリアン作」という表題が付けられている。

参考リソース

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

検証

チェックポイント
  1. 簡潔な代替テキストで内容が分かる名前を提供している。

  2. 簡潔な代替テキストで非テキストコンテンツに作者や他の人によって以前から付けられている名前を提供している。

判定基準
  • 1.又は2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

  • 辞書にはその単語の定義がいくつかあるが、コンテンツを理解するためには一つの特定の定義が用いらなければならない。

  • コンテンツを理解するために特定の定義が用いられている、又辞書には、それらの定義はまれな、廃れた、旧式のと書かれている。

  • コンテンツ制作者が、コンテンツを理解するために用いられる新しい定義を作り出す。

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

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

事例

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

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

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

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

事例 3: 業界用語

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

事例 4: 固有表現

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

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

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

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

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

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

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

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

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

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

参考リソース

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

検証

チェックポイント

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

  1. 単語又は語句に対して定義が提供されている。

判定基準
  • 1.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

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

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

略語ラテン語の表記語の説明
a.m.ante meridiem正午より前。午前。
p.m.post meridiem正午より後。午後。
e.g.exempli gratia例えば。
cfconfer/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」は英語の一部になっており、元の語を提供する必要はない。

参考リソース

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

検証

チェックポイント

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

  1. 略語に元の語が無い場合は、説明を提供されている。

  2. 略語の元の語がコンテンツとは異なる言語の場合は、説明が提供されている。

  3. それ以外の場合は、元の語が提供されている。

判定基準
  • 上記の全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G103: アイデア、事象及びプロセスの説明を理解しやすくするために、視覚的な図画、写真及びシンボルを提供する

適用(対象)

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

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

解説

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

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

  • 図表やグラフは、複雑なデータの理解に役立つ。

  • 略図、フローチャート、ビデオ、アニメーションは、プロセスの理解に役立つ。

  • 概念図及び他の統合図は、アイデア同士の関係を理解するのに役立つ。

  • 写真、デッサン、ビデオは、自然や歴史上の出来事や対象の理解に役立つ。

事例

事例 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.

(今のところ、なし。)

検証

チェックポイント
  1. コンテンツの利用にあたって理解が不可欠なアイデアやプロセスを説明しているテキストを特定する。

  2. コンテンツの中で、あるいは、コンテンツ内のリンクを通じて、視覚的な図画が利用できる。

  3. 視覚的な図画が、テキストで説明している概念やプロセスを表わしている。

判定基準
  • 2. 及び 3. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

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

事例

検証

チェックポイント

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

  1. ログインし、制限時間のある操作を始める。

  2. セッションを時間切れにさせる。

  3. データを送信する。

  4. 再認証する。

  5. 再認証後に元のデータや変更内容が保持された状態で、その後のプロセスが継続可能で、データの欠落なく完了できる。

判定基準
  • 5. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G107: 状況の変化に対するトリガーとして、"focus" ではなく、"activate" を使用する

適用(対象)

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

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

解説

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

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

事例

事例 1
  • ページが新しいウィンドウをポップアップ表示するのは、利用者がフォーカスを移動させたときではなく、ボタンをクリックした(又はスペースバーを使った)ときのみとする。

  • 利用者が完了ボタンにタブで移動したときに自動的に次の画面を表示するのではなく、送信ボタンを使用したときに次のデータ入力画面に移動するようにする。

参考リソース

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

(今のところ、なし。)

検証

チェックポイント
  1. キーボードを利用して、全てのコンテンツへフォーカスを移動させる。

  2. どの構成要素がフォーカスを受け取っても状況の変化が発生しない。

判定基準
  • 2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G108: マークアップを用いて、名前及び役割をユーザエージェントに提供し、利用者が設定可能なプロパティを直接設定可能にし、変化を通知する

適用(対象)

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

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

解説

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

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

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

構成要素がアクセシビリティをサポートしている時でさえ、コンテンツ制作者によって提供される情報は必要不可欠である。 例えば、コントロールは識別名を提供する能力を持っているかもしれないが、コンテンツ制作者はそれでも名前を提供しなければならない。 また一方、それは固定の役割のある標準的な構成要素であるため、役割の属性はすでに提供されているかもしれない。

事例

事例 1

HTML又はXHTMLで書かれたウェブページは標準的なフォーム・コントロールを使用し、タイトル属性を使用して フォーム・コントロールを特定している。ユーザエージェントは、これらコントロールに関する情報を、名前を含めて生成する。そして、DOMとプラットフォーム特有のアクセシビリティAPIを通して支援技術が利用可能となる。

参考リソース

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

検証

チェックポイント
  1. マークアップを見て確認する、又はツールを使用する。

  2. それぞれのユーザインタフェースの構成要素に対して、識別名と役割を決定することができるように適切なマークアップが使用されている。

  3. 利用者の入力を受け取るユーザインタフェース要素が全て支援技術から操作することができるように適切なマークアップが使用されている。

判定基準
  • 各ユーザインタフェースの構成要素において、2.と3.の両方を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G110: クライアントサイドの瞬間的なリダイレクトを使用する

適用(対象)

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

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

解説

この達成方法の目的は、クライアントサイドで利用可能なリダイレクトを、利用者を混乱させることなく用いることである。リダイレクトはサーバサイドで実装するほうが望ましい(SVR1: クライアントサイドではなく、サーバサイドで自動リダイレクトを実装する[サーバー]を参照)。なぜなら、サーバーサイドのリダイレクトでは、新たなURIにあるコンテンツをサーバが送信する前にコンテンツが表示されてしまうことがないからである。しかし、コンテンツ制作者がサーバサイド技術を管理しているとは限らず、このような場合にはクライアントサイドのリダイレクトを用いることができる。コンテンツを異なるURIから取得すべきことをユーザエージェントに指示するコードを埋め込むことで、クライアントサイドのリダイレクトが実装できる。リダイレクト元のページには、リダイレクトに関する情報のみを含めておくことが重要である。

事例

事例 1: HTML:meta要素のrefreshで、URIを指定し、タイムアウトを指定しない方法

HTML 4.xとXHTML 1.xでは、mata要素を用いることでクライアントサイドのリダイレクトが実装できる。H76: meta要素のrefreshを用いて、クライアントサイドで瞬間的にリダイレクトする(HTML)を参照のこと。

参考リソース

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

検証

チェックポイント
  1. 他のウェブページへのリンクやプログラム参照を見つける。

  2. 各リンクやプログラム参照について、参照先のウェブページにクライアントサイドのリダイレクト用のコード(meta要素やスクリプトなど)が含まれている。

  3. クライアントサイドのリダイレクトが生じるリンクやプログラム参照について、リダイレクトは時間制限も遅延もなく実装され、そのページにはリダイレクトに関する情報のみが含まれている。

判定基準

2.を満たしていない、又は3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G111: 色とパターンを併用する

適用(対象)

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

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

解説

この達成方法の目的は、非テキストコンテンツの中で情報を伝達するために色の違いを用いている場合に、色に依存することなく同じ情報を伝達するためにパターン(模様)を併用することである。

事例

事例 1

不動産会社のサイトに、米国のいくつかの地域における平均住宅価格の棒グラフがある。それぞれの地域を表す棒は、異なる色とパターンになっている。色とパターンの色とのコントラスト比は十分にあり、達成基準1.4.1を満たしている。凡例にもそれぞれの棒が識別できるように、同じ色とパターンが使用されている。

事例 2

交通システムのオンライン地図には路線が色分けされている。それぞれの路線上の停車場は菱形、正方形又は円など、区別しやすいアイコンになっており、路線を区別しやすくしている。

事例 3

プロセスを完了するまでのインタラクティブな一連の手順を示すフローチャートがある。フローチャートでは、緑色の背景に破線の矢印で条件を満たした場合に進む次のステップを示しており、赤の背景に点線の矢印で条件を満たしていない場合に進む次のステップを示している。線と背景色には達成基準1.4.1を満たす十分なコントラストがある。

事例 4

コンテンツにはインタラクティブなゲームがある。4人分のゲームのコマは、色とパターンの両方を使っておりそれぞれ識別できるようになっている。

参考リソース

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

検証

チェックポイント

ウェブページ上にある情報を伝達するために色の違いを用いている画像に対して:

  1. 色を用いて伝達されている情報の全てに、色に依存しないパターンも併用している。

判定基準
  • 1.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G112: インラインの定義を使用する

適用(対象)

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

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

解説

この達成方法の目的は、一般的ではない、又は限定された用途で用いられているあらゆる用語に対して文脈の中で定義を提供することである。定義は、単語が使われている直前又は直後のいずれかに、テキストで提供される。定義は、定義される単語として同じ文章の中、又は異なる文章の中に記載されることが望ましい。

事例

事例 1: エーテル

彼はエーテルを介して音が伝わると信じていた。それは、宇宙空間に満たされている物質と考えられていた。

事例 2: ドライバー

プリンタのドライバーをアップデートする必要があるかもしれない (ドライバーはプリンタの特定の指示を含んでいるソフトウェアである)。

事例 3: W3Cのキーワード

定義: この基準で、「しなければならない(must)」、「してはならない(must not)」、「しなければならない(required)」、「しなければならない(shall)」、「してはならない(shall not)」、「することが望ましい(should)」、「しないほうがよい(should not)」、「することが望ましい(recommended)」、「してもよい(my)」、及び「してもよい(optional)」のキーワードは、RFC 2119に記載されている解釈による。

事例 4: 文脈中で定義された日本語の慣用句の表現

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

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

参考リソース

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

検証

チェックポイント

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

  1. 単語の初出箇所の前か後ろのいずれかで、単語がテキストで定義されている。

判定基準
  • 1.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G115: 構造をマークアップするために、セマンティックな要素を使用する

適用(対象)

HTML 4.01及び XHTML 1.xを含むマークアップ言語

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

解説

この達成方法の目的は、適切なセマンティックな要素を用いてウェブコンテンツの構造をマークアップすることである。つまり、要素を、視覚的な見えかたではなく、その意味に基づいて用いることである。

適切なセマンティックな要素を用いることで、ユーザエージェントが構造を利用できるようになる。この中には、コンテンツの意味を理解する際に、異なる構成要素が持っている役割(role)を明示することも含まれる。段落、見出し、強調されたテキスト、テーブルなどのコンテンツの構成要素の性質は、このようにして示すことができる。場合によっては、見出しと小見出し、テーブルとセルといった複数の構成要素間の関係も示されるべきである。そうすることで、ユーザエージェントは、たとえば、異なる種類の構造に対しては異なる視覚表現にしたり、聴覚表現では、異なる声又は声の高さを用いたりして、利用者に構造を知覚させることができるようになる。

例えば、HTMLにおいては、emabbr及びciteといった語句レベルの要素は、それぞれ、強調させるため、略語及び引用であることを示すためにテキストをマークすることで、文の中でセマンティックな情報を付加する。 数学における構造と表現の重要な区別を保つために設計されたマークアップ言語であるMathMLには、数学的な概念を表すために用いられる複雑な記号のための特別な「表現」のマークアップも、数学的な概念自体のための「コンテンツ」(セマンティック)マークアップも含まれている。

事例

事例 1

段落には別のページへのハイパーリンクがある。ハイパーリンクはa要素を用いてマークアップされている。

コード例:


<p>我々の新しいツールをご自身で試したいですか?
<a href="downlod.html">ダウンロードコーナー</a>で無料の体験版が入手できます。</p>
      
事例 2

結婚の歴史についてのページには、ジェーン・オースティンの小説「高慢と偏見」からの引用が事例として用いられている。本への参照は、cite要素を用いてマークアップされ、引用部分自体はblockquote要素を用いてマークアップされている。

コード例:


<p><cite>高慢と偏見</cite>という小説の第1章にあるように、
結婚は独身男性にとって必然的な段階と考えられていた:</p>
<blockquote>
<p>多くの財産を持った独身男性は妻を必要としているということは、
広く認められた普遍的な真実である。</p>
<p>しかしながら、彼が初めて隣人となったばかりのころは、
このような男性の気持ちやものの見方はほとんど知られてはいなかったが、
この真実は周囲の家々の人の心に定着し、彼は隣人たちの娘の誰か
の正当な所有物であると考えられるようになる。</p>
</blockquote>
      
事例 3

車の取扱説明書にエンジンのかけ方の説明がある。説明書きには、ギアがニュートラルになっていることを確かめるようにとの警告がある。筆者は、その警告は非常に重要で強調されるべきであると考えていたため、警告はstrong要素を用いてマークアップされている。

コード例:


<h1>エンジンの始動法</h1>
<p>エンジンをかける前に<strong>ギアがニュートラルになっていることを確認する</strong>。
次にキーを点火の位置まで回す。
エンジンは始動する。</p>
            
事例 4

この事例では、テキストを強調するためにem 及び strong要素をどのように用いたらよいかを示している。

コード例:


<p>彼女が<em>本当に</em> 言おうとしていたのは、
「良いのではない、<strong>すばらしい</strong>のだ!」</p>
            
事例 5: 強調及び背景色を用いて重要な情報を視覚的かつセマンティックに特定する。

コード例:


<style type="text/css">
.vocab {
background-color:cyan;
font-style:normal;
}
</style>
.......
<p>新出単語は強調され、背景色が空色になっている</p>
<p>その芝居への<em class="vocab">痛烈な</em>批評はやや行きすぎのようであった。 </p>
            

参考リソース

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

検証

チェックポイント
  1. セマンティックな機能を有するコンテンツがある。

  2. セマンティックな機能がある部分に対応するセマンティックなマークアップがウェブコンテンツ技術に存在する場合、コンテンツがそのセマンティックなマークアップを用いてマークアップされている。

判定基準
  • 2を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G117: テキストの表現のバリエーションによって伝えている情報を伝達するために、テキストを使用する

適用(対象)

テキストの視覚的な表現のバリエーションをサポートするウェブコンテンツ技術

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

解説

この達成方法の目的は、テキストの書式のバリエーションを通じて伝達される情報を同様にテキストで伝達することである。テキストの視覚的な見た目を変えて情報を伝達する際には、テキストでその情報を明確に提示すべきである。フォントの書体、サイズ、下線、取り消し線及びその他の様々なテキスト属性を変えることによって、視覚的な見た目にバリエーションをもたせることができる。このようなバリエーションが何らかの情報を伝達している際には、その情報がコンテンツのどこか他の場所でテキストによっても入手可能である必要がある。ドキュメント内に補足説明を加えること、又はテキストの表現のバリエーションを用いている箇所にインラインで説明を加えることによって、その情報を伝達することができる。

事例

事例 1: 新しいコンテンツをボールドの文字とテキストで示す

以下の例はアクセシビリティ標準のリストである。WCAG 2.0は新しいため、ボールドで表示されている。視覚のみで情報が提供されることを避けるため、「(new)」という単語も後ろにつけている。

コード例:


          <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: テキスト内のどの単語に異なるフォントが当てられているか知るための代替手段を提供する

あるオンラインテストでは、学生に対し、長い文章の短い要約を書くことを求めている。その要約には、原文にあるいくつかの単語を含めなければならない。原文では、要約に用いなければならない単語やフレーズが、他と異なるフォントで表示されている。独立したセクションにおいても、要約で用いなければならない単語やフレーズすべてがリスト化されてる。

参考リソース

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

検証

チェックポイント
判定基準

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G120: 単語のすぐ後に発音(読み)を提供する

適用(対象)

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

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

解説

この達成方法の目的は、単語がウェブページの中で少なくとも最初に現れたとき、後ろに読みを提供することにより単語の読み方が分かるようにすることである。

同じつづりで異なった読みの単語がウェブページにあるときは、その単語が現れるごとに読みが提供されない場合、この達成方法は読みの提供として適切なものとはならない。

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

事例

事例 1: Example 1

以下の日本語のテキストの例では、漢字の読みを与える情報は、テキストの直後の丸括弧の中に描画される。

コード例:

<p> 慶應大学 (けいおうだいがく) </p>

参考リソース

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

検証

チェックポイント

読みを必要とする単語それぞれに:

  1. ウェブページのなかで、その単語の最初の使用箇所を探す。

  2. 最初の使用箇所の直後にその単語の読みがある。

判定基準
  • 2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G121: 発音(読み)にリンクする

適用(対象)

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

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

解説

この達成方法の目的は、単語の発音に関する情報を同じウェブページ又は異なるウェブページ上で提供し、対象となる単語から発音の情報へリンクすることにより、その単語の発音を入手可能にすることである。

事例

事例 1

単語がその発音情報を含む辞書にリンクされている。

事例 2

単語がその発音を含む音声ファイルにリンクされている。

事例 3

単語が発音辞書(発音音声を提供することを目的とした辞書)にリンクされている。

事例 4

単語がその発音のInternational Phonetic Alphabet(IPA)表現にリンクされている。

事例 5

単語がその発音を曖昧性のないように書き下したスペリングにリンクされている。

参考リソース

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

検証

チェックポイント

発音情報を提供すべき単語の全てについて:

  1. 少なくともその単語の最初の出現箇所がリンクになっている

  2. そのようなすべてのリンクが単語の発音に関する情報にリンクしている。

判定基準
  • 上記全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G123: 繰り返しているコンテンツのブロックの開始位置に、そのブロックの終了位置へのリンクを追加する

適用(対象)

リンクを実装できる全てのウェブコンテンツ技術

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

解説

この達成方法の目的は、ブロックの終わりまで飛び越えることで、構成要素のブロックを回避するメカニズムを提供することである。ブロックの最初のリンク又はブロックの直前にあるリンクによって、フォーカスをそのブロックの直後にあるコンテンツに遷移させる。リンクを選択することでキーボードフォーカスはブロックを飛ばして進んでいく。複数のブロックを飛び越える場合は、利用者はこれらのリンクを使ってブロックを一つずつスキップしていく。

事例

事例 1: ナビゲーションリンクをスキップする

ある組織のウェブサイトのページには、サイトの主なセクション、サイトマップ、組織についての情報、及び組織との連絡方法へのリンクを含むナビゲーションバー又はメインメニューがある。このエリアの最初のリンクは「ナビゲーションリンクをスキップする」で、利用者はそのリンクを選択してこれらのリンクをスキップする。

事例 2: 本の索引

本の中に何ページかのセットになって区分されている索引がある。索引のそれぞれのページの冒頭にあるコンテンツの中には、アルファベットのそれぞれの文字に対するリンクがあり、その文字で始まる記載内容の索引にリンクしている。そのセットの中の最初のリンクは「リンクをスキップして索引へ」である。利用者は、このリンクを選択して他のリンクをスキップする。

事例 3: 複数のリンクの集合

ウェブサイト内の全てのページにはサイトマップ、組織に関する情報、及び組織との連絡方法へのリンクが含まれているセクションがある。サイトにある各セクションの全てのページには、同様にその下位の区分へのリンクの集合がある。1番目のブロックの最初のリンクは「ナビゲーション・リンクをスキップ」で、最初のリンクの集合をスキップする。2番目のブロックの最初のリンクは「セクションのリンクをスキップ」で、そのサブセクションのリンクをスキップする。

事例 4: ナビゲーション・リンクのブロックが複数あるHTMLページ

この事例では、各セクションの冒頭の見出し要素(達成方法 H69)、及びそれぞれのセクションの最後までスキップするリンクの両方が用いられている。利用するユーザエージェントの能力に依存するが、これによってキーボード・ナビゲーション又は見出しナビゲーションを用いて、繰り返されるコンテンツのブロックをスキップすることができる。

コード例:


              <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%;
                }
            

参考リソース

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

検証

チェックポイント
  1. リンクが、繰り返されるコンテンツのブロックの前にある最後のフォーカス可能なコントロールである、又はブロック内の最初のリンクである。

  2. リンクテキストがブロックをスキップすることを伝えている。

  3. リンクは常に表示されている、又はキーボード・フォーカスを受け取ったときに表示される。

  4. リンクを選択すると、そのブロックの直後のコンテンツにフォーカスが移動する。

判定基準
  • 上記の全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G124: ページの先頭に、コンテンツの各エリアへのリンクを追加する

適用(対象)

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

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

解説

この達成方法の目的は、コンテンツの異なるセクションへのリンクのリストを提供することによって、文書のブロックをバイパスするメカニズムを提供することである。このリストにある複数のリンクは、コンテンツの最初にある小さな目次のようなものであり、その中のリンクはコンテンツ内のさまざまなセクションへフォーカスを設定する。この達成方法は、ポータルサイトのような多くの独立したセクションがあるページに対して特に有効である。これはセクション内でのブロックをスキップする他の達成方法と組み合わせることもできる。

事例

事例 1

サイト内のウェブページはすべて、そのページのメインコンテンツ、検索フィールド、及びナビゲーションバーにナビゲートする3つのリンクで始まる。

参考リソース

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

検証

チェックポイント

この目的のために提供されているリンク一式にある各リンクに対して:

  1. ウェブページの中でそのリンクより前にあるコントロールは、その一式にある他のリンクだけである。

  2. 各リンクの説明(リンクテキスト)がコンテンツ内のあるセクションへのリンクであることを説明している。

  3. そのリンクが常に表示されている、又はキーボード・フォーカスを受け取ったときに表示される。

  4. そのリンクを起動(実行)すると、コンテンツの目的のセクションへフォーカスを移動させる。

判定基準
  • 上記全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G125: 関連するウェブページへナビゲートするリンクを提供する

適用(対象)

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

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

解説

この達成方法の目的は、関連するウェブページへのリンクを提供することによって利用者が追加情報の場所を特定できるようにすることである。 それは、達成基準 2.4.5の実装に十分なコンテンツを配置するための一連の達成方法の一つである。 リンクは、World Wide Webの基本的な構成要素であり、ウェブを相互接続されたウェブコンテンツにするメカニズムである。大半のウェブコンテンツ制作者は、ウェブページを制作する場合に無意識にこの技術を用いている。

事例

事例 1

ウェブ・コンテンツ・アクセシビリティ・ガイドライン 2.0は、ガイドラインと達成基準の中で使われる用語を定義したドキュメントへのリンク、異なる達成基準をどのように満たすかを説明したドキュメントへのリンク、 そのセクションの異なるサブセクションへのリンクを含む各セクションの目次、及びComparison of WCAG 1.0 checkpoints to WCAG 2.0(英語)へのリンクを含んでいる。利用者がこのドキュメントを拾い読みするときは、これらのリンクをたどって関連情報を探すことができる。

参考リソース

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

検証

チェックポイント

ウェブページ内の各リンクに対して:

  1. そのリンクが関連する情報へのリンクである。

判定基準
  • 1.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G126: 他の全てのウェブページへのリンク一覧を提供する

適用(対象)

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

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

解説

この達成方法の目的は、個々のウェブページを一組として全てのウェブページへのリンク一覧を提供することである。達成基準 2.4.5 を実装するのに十分なコンテンツを配置するための一連の達成方法の一つである。この達成方法は、小規模なウェブページに対してのみ効果がある; リンク一覧がウェブページ内の残りのコンテンツより長い場合、利用者がウェブページを理解して使うことをより困難にするかもしれないからである。

注記: 達成基準 2.4.1 は、このリンクの一覧をスキップするための達成方法を要求している。

事例

事例 1

家族のウェブサイトには、家族の構成員全てのウェブサイト(サブサイト)がある。個々のページには、他の家族構成員のウェブサイトへのリンク一覧がある。

事例 2

電子ブックでは、各章が別々のウェブページに分けられている。個々のウェブページは、本の中の全ての章へのリンクを含む小さな目次で始まる。

参考リソース

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

検証

チェックポイント
  1. 個々のウェブページに、サイト内の他のウェブページへのリンク一覧がある。

  2. 一覧内のリンクが対応するウェブページにリンクしている。

  3. 一覧には、サイト内の全てのウェブページに対するリンクがある。

判定基準
  • 上記全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G127: 技術特有の達成方法を用いて、そのウェブページとその他の多くのウェブページとの関係を示す

適用(対象)

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

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

解説

この達成方法の目的は、利用者がそのウェブページと同じ一式(例:同じウェブサイト)にあるウェブページとの関係性を特定できるようにすることである。場合によっては、プログラムが解釈できるように実装することが可能である。例えば、HTMLでは、link要素のrel属性を用いることができる。また、ウェブページのタイトルに関連する情報を含めることによって、関係性を示す情報を提供することもできる。

事例

事例 1: サブサイト名を含んだウェブページのタイトル

ある大規模なウェブサイトに、数々のウェブコンテンツ技術に関するチュートリアルとリファレンスがある。各ウェブページのタイトルには、そのサイトを提供している組織名とサブサイト名とがある。

事例 2: 特定できる情報を含んだメタデータ

あるウェブページには、それが文書一式の目次であることを示すメタデータがある。その文書一式にある各文書のメタデータは、一式の中におけるその文書の位置付けを特定しており、目次への参照を提供している。

事例 3: オンライン教科書の各章

あるオンライン教科書が幾つかの章に分けられている。各ウェブページのタイトルには、教科書のタイトルに加えて、その章の章番号とタイトルがある。

参考リソース

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

検証

チェックポイント
  1. ウェブページのタイトルが、そのウェブページの属するウェブページ一式との関係性を示している。

  2. ウェブページに、そのウェブページの属するウェブページ一式との関係性を特定するメタデータがある。

判定基準
  • 1. 又は 2. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G128: ナビゲーションバー内で現在位置を示す

適用(対象)

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

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

解説

この達成方法の目的は、ナビゲーションに関するユーザインタフェースを通じて、現在位置の情報を提供することによって、利用者が現在位置を確認しやすくすることである。この達成方法は、順序立てて処理すべきタスクを、複数のウェブページで段階的に説明している場合に役立つ。このような表示の提供は、利用者が一連の文書の中で自分の位置を正しく把握するのに役立つ。アイコンやテキストを追加したり、その項目の状態を変化させることで、位置を示すことができる。

事例

事例 1

あるウェブページにタブパネル型のナビゲーションが設置してある。タブのリストは横並びに表示されている。現在のコンテンツはタブの下のパネルに表示される。利用者がタブを選択すれば、選択したタブに合わせてパネル内のコンテンツが更新される。さらに、パネルを開いたことを示すために、選択したタブの背景色は初期状態とは異なる色に変化し、テキストの横にチェックマークアイコンが表示される。チェックマークアイコンには、適切な代替テキストを指定してある。

事例 2

あるウェブページのレイアウトに、フレームセットと複数のフレームを用いている。フレームの1つをナビゲーションのためのフレームとし、もう一方のフレームにはウェブサイトのコンテンツを表示させている。利用者がナビゲーションフレーム内のリンクを選択したら、そのリンクに合った情報がコンテンツフレームに表示される。ナビゲーションフレーム内で選択した項目には、それが選択したトピックであることを示すためにアスタリスクが追加される。

事例 3

あるウェブサイトのナビゲーションバーは、複数のリンクのリストとして設置されている。ナビゲーションバーは、全てのウェブページに設置してある。利用者がナビゲーションバー内のリンクにフォーカスするかマウスオーバーしたときに、リンクの背景色が変化する。フォーカスやマウスオーバー時のスタイルの変更は、ウェブページに適用しているカスケーディングスタイルシートで行なっている。リンクからフォーカスが外れたら、通常のリンクのスタイルに戻る。別のページを見るためにリンクをアクティブにした場合、選択したリンクは動作しないようになる。このリンクを選択した結果として、現にそのページが表示されているからである。背景色の変更は、選択したリンクであるという視覚的な通知を利用者に与える。リンクが動作しないようにすることで、現在選択しているトピックであるという情報を全ての利用者に提供する。

参考リソース

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

検証

チェックポイント

ウェブページ一式に同じナビゲーションバーが繰り返し用いられている場合:

  1. ナビゲーションバー内で、現在選択されているアイテムが示されている。

  2. 選択されているアイテムと現在表示されているコンテンツが合っている。

判定基準
  • 1. 及び 2. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G130: 内容が分かる見出しをつける

適用(対象)

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

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

解説

この達成方法の目的は、ウェブ・コンテンツ内の見出しがコンテンツの内容を表すようなものにすることである。コンテンツの内容が分かるような見出しやタイトル(「G88: ウェブページに対して、コンテンツの内容が分かるページタイトルを提供する」参照)を用いることで、利用者に対してコンテンツの概要と構成を提示することができる。内容を表す見出しをつけることで、そのセクション(節)のウェブページ中の位置づけと、他のセクションとの関係を明確にすることができる。

内容を表す見出しがあれば、利用者は目的のコンテンツを見つけることや、ウェブページ内のどの部分を読んでいるのかを知ることが容易になる。

コンテンツ制作者は、最も重要な情報を各見出しの先頭に配置することを検討すると良いだろう。これによって、利用者は斜め読みをして必要な情報を見つけることが容易になる。特に、見出しから見出しへのナビゲーションが可能なブラウザや支援技術を用いている場合には有効である。

事例

事例 1

災害対策を示すHTMLページで、以下のような見出しが使われている:

コード例:


  <h1>災害対策</h1>
  <h2>洪水対策</h2>
  <h2>火災対策</h2>

レベル2の見出しは、先頭に内容を識別できる情報が配置されていることに注意されたい。 (すなわち、「対策 : 洪水」、「対策: 火災」などとはなっていない。)

事例 2

ある町について書かれた短い記事がある。この記事は、町の起こり、拡大、そして現状に関する詳しい説明を含んでいる。ウェブページのタイトルは「私たちの町の歴史」である。最初のセクションのタイトルは「我が町の始まり」で、2番目のセクションのタイトルは「我が町の拡大」である。3番目のセクションのタイトルは「今日の我が町」で、このセクションには、「町の人々」、「町の組織」、「町の施設」というサブセクションがある。

参考リソース

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

検証

チェックポイント
  1. ウェブページに見出しがある。

  2. 各見出しが、ウェブページ中の対応するセクションを表す内容になっている。

判定基準
  • 2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G131: 目的や内容が分かるラベルを提供する

適用(対象)

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

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

解説

この達成方法の目的は、ウェブコンテンツ内のあらゆるインタラクティブなコンポーネントに対するラベルにより、コンポーネントの目的を明確にすることである。そのウェブコンテンツ技術において、ラベルとインタラクティブなコントロールを関連付けるための適切な達成方法によって、支援技術はラベルを認識し利用者に提示できるようになる。そのため、利用者はコントロールの目的を認識することができる。ラベルは、インプットが要求されるテキスト又はテキストシンボルに使用されても良い。

事例

事例 1: 拡大、縮小機能のコントロールのあるオンライン地図

ある市の地図をウェブアプリケーションで提供している。利用者は「ズームイン」を使ってより詳細な地図が見られ、「ズームアウト」で市の広い地域を見ることができる。マウスとキーボードのいずれでも操作することができる。コントロールには「ズームイン(Ctrl +Shift + L)」と「ズームアウト(Ctrl + +Shift + R)」というラベルが提供されている。

事例 2: 利用者の名前を入力させるフォーム

利用者の名前を入力させるフォームがある。そのフォームには、姓と名を入力するために2つのフィールドがある。1つ目のフィールドには「姓」というラベルがあり、2つめには「名」というラベルがある。

事例 3: 必須入力のあるフォーム

必須の入力項目がいくつかある注文票がある。必須入力のフィールドには、フィールドの項目名に加えて「(必須)」と括弧書きされている。

参考リソース

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

検証

チェックポイント

コンテンツ中のインタフェースコンポーネントに対して:

  1. インタフェースコンポーネントの目的を特定する。

  2. ラベルが提供されている。

  3. ラベルはコンポーネントの目的を明確に示している。

判定基準
  • 2.及び3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G133: 複数の画面で構成されるフォームの最初のページに、利用者がセッションの制限時間を延長又は解除できるチェックボックスを提供する

適用(対象)

複数の画面で構成されるフォームのあるコンテンツ

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

解説

この達成方法の目的は、複数の画面で構成されるフォームを記入するにあたって時間の延長を要求できるチェックボックスを提供することにより、障害のある利用者が途中まで記入した内容を失うリスクを最小化することである。このチェックボックスによって、利用者は、具体的にどれだけの時間を追加したいか(例えば15分など)、あるいは無限に延長したいかを要求できるようになる(ただし、利用者のプライバシーやネットワークのセキュリティを危険にさらす恐れがある場合、無限に延長できるようにすることは適切ではない)。

事例

事例 1: 具体的な延長時間を要求するチェックボックス

5つのパートで構成されるフォームの最初のパートがウェブページに表示されている。フォームの記入方法に関する一般的な説明のすぐ後に、「フォームの各パートの記入に必要な時間を15分延長する」というラベルのチェックボックスがある。

事例 2: 無限の延長を要求するチェックボックス

3つのパートで構成されるフォームの最初のパートがウェブページに表示されている。各パートにそれぞれ10個以上の入力項目がある。それらの入力項目のなかには、リンクをたどって付加的な情報を見なければならないものもある。フォームの記入方法に関する一般的な説明のすぐ後に、「フォーム記入に必要な時間を無限に延長する。また、最後のパートを記入する前にフォームの記入をやめる場合は、ウェブブラウザを閉じなければならないことに同意する。」というラベルのチェックボックスがある。

検証

チェックポイント

ウェブページに、複数の画面で構成されるフォームの最初のパートがある場合:

  1. ウェブページにフォーム入力を完了させるための追加時間を要求するチェックボックスがある。

  2. チェックボックスが選択されている場合、フォーム入力を完了させるための追加時間が提供されている。

判定基準
  1. 全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G134: ウェブページをバリデートする

適用(対象)

全てのマークアップ言語及びその他の多くのウェブコンテンツ技術

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

解説

この達成方法の目的は、正式な仕様に則ってバリデートされていないコードにしばしば起因するウェブページの曖昧さをなくすことである。ウェブコンテンツ技術及びそのバージョンを特定するために、それぞれのウェブコンテンツ技術に備えられているメカニズムを用いて、そのウェブコンテンツ技術の正式な仕様に照らし合わせてウェブページをバリデートする。対象となるウェブコンテンツ技術にバリデータがある場合、コンテンツ制作者/開発者はそれを使うことができる。

通常は、バリデーションによって曖昧さ(及びその他の問題点)を排除することが可能である。これは、バリデーションに不可欠なステップの一つが、ウェブコンテンツ技術のマークアップ(マークアップ言語)又はコード(他のウェブコンテンツ技術)が適正に使用されているかどうかをチェックすることだからである。バリデーションは、必ずしも仕様への完全な準拠をチェックするものではないが、コンテンツを仕様に照らし合わせて自動チェックするには最適な手段である。

事例

事例 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>

参考リソース

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

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ベースのウェブコンテンツ技術に対して:

  1. それぞれのページ又はドキュメントをバリデーションを行うパーサーで読み込む。

  2. バリデーションエラーがない。

その他のウェブコンテンツ技術に対して:

用いているウェブコンテンツ技術に対してバリデーションの手順が定められていれば、それに従う。

判定基準

HTML、SGMLベース、及びXMLベースのウェブコンテンツ技術に対して:

2. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G135: 名前及び役割をユーザエージェントに提供し、利用者が設定可能なプロパティを直接設定可能にし、変化を通知するために、ウェブコンテンツ技術のアクセシビリティ API を使用する。

適用(対象)

アクセシビリティAPIと連動するようにプログラムされた標準コンポーネントを持つプログラミング・ウェブコンテンツ技術。

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

解説

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

コンテンツは、マークアップ言語を用いず、プログラミング言語又はツールを用いて制作されることがある。多くの場合、これらのウェブコンテンツ技術には、既にアクセシビリティAPIと連動するようにプログラムされたインタフェース・コンポーネントがある。コンテンツ制作者がそういったコンポーネントを使用して、プロパティ(例えば名前など)を記述すれば、生成されたコンテンツのユーザインタフェース・コンポーネントは支援技術に対してアクセシブルとなる。

事例

事例 1
  • ウェブページがアプレットを作るためにJavaを使用している。Java Swingオブジェクト(例えばプッシュボタン)が使われているのは、Javaで書かれた支援技術からアクセスできる標準搭載のアクセシビリティ・プロパティ、及びJava Access BridgeとともにOSのアクセシビリティAPIを用いる他の言語で書かれたアクセシビリティプロパティを持っているためである。コンテンツ制作者がそのコンポーネントに対して値を記述することによって、そのコンポーネントは支援技術にとってアクセシブルなものとなる。

参考リソース

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

(今のところ、なし。)

検証

チェックポイント
  1. アクセシブルなユーザエージェントを用いてコンテンツを描画する。

  2. 各ユーザインタフェース・コンポーネントを評価するために、ユーザエージェントのアクセシビリティAPIに対応して設計されたアクセシビリティツールを使用する。

  3. 各インタフェース・コンポーネントの名前(name)及び役割(role)が、そのツールによって確認できる。

判定基準
  • 各インターフェース要素について、3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G136: 適合していないウェブページの先頭に、適合している代替版へのリンクを提供する

適用(対象)

本来のコンテンツはWCAGに適合していないが、WCAGに適合している代替版は存在している。この達成方法を用いることができるのは、ウェブコンテンツ技術が代替版へのアクセシブルなリンクを作ることを可能としている場合のみである。

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

解説

この達成方法の目的は、本来のコンテンツ又は利用者が特定のURIに訪れた時に遭遇するデフォルトのコンテンツがWCAGに適合していない場合、利用者がWCAGに適合している代替コンテンツにアクセスできるようにすることである。代替ページ又は適合している代替版は、適合するためにいくつかのデザイン又は機能的な譲歩を作る可能性があるが、適合している代替版にするためには定義において記された要件を満たさなければならない。「適合している代替版」の定義とは:

適合している代替版 (conforming alternate version)

以下の事項を満たす版のことを指す:

  1. 指定されたレベルで適合しており、かつ

  2. 同じ情報及び機能のすべてを同一の自然言語で提供しており、かつ

  3. 不適合コンテンツと同時に更新されていて、かつ

  4. 以下に挙げる事項のうち少なくとも一つを満たしていること:

    1. アクセシビリティ サポーテッドメカニズムを用いて、 不適合ページから適合版へ到達できる。もしくは、

    2. 不適合版に到達できるのは、適合版からのみである。

    3. 不適合版に到達できるのは、適合版に到達するメカニズムも提供している適合ページからのみである。

注記 1: この定義において、「到達できるのは……からのみ」とは、利用者が適合版から来ていない限り、不適合ページに「到達する」 (読み込む) のを防ぐ条件付きリダイレクトのような何らかのメカニズムがある、ということを意味する。

注記 2: 代替版は、元のページと一対一で対応している必要はない (例えば、適合している代替版は複数のページであってもよい)。

注記 3: 複数の言語版が利用できる場合、各言語版に対して、適合している代替版を提供する必要がある。

注記 4: 様々な技術環境、又は利用者層に対応するために、複数の代替版を提供してもよい。この場合、各版は可能なかぎり適合したものでなければならず、適合要件 1を満たすためには、そのうちの一つの版が完全に適合したものでなければならない。

注記 5: 不適合版と同じように自由に利用可能であるかぎり、適合している代替版は、適合宣言の範囲に含まれている必要はなく、同一のウェブサイト上で提供されている必要もない。

注記 6: 代替版は、元のページを補助して理解を高める補足コンテンツと混同されないようにすべきである。

注記 7: コンテンツ内で利用者が設定を行うことで適合版が作り出される仕組みは、その利用者の設定に用いられている手法がアクセシビリティ サポーテッドであるかぎり、代替版への到達メカニズムとして条件を満たしているといえる。

Understanding Conforming Alternate Versionsを参照。

この実装方法を使用している際、ページの最初に代替コンテンツへのWCAGに適合したリンクを配置することで、利用者がそのリンクをすぐに見つけることができ、適合している代替版に移動することができるようになる。利用者がどこからそのサイトに入ったかに関係なく、利用者が常に代替版を見つけることができるようにするためには、特定のレベルで適合していないページには適合している代替版へのリンクを含めることである。

事例

  • ウェブサイト上で宣言しているレベルでWCAGに適合していない各ページにおいて、ページの最初に「アクセシブルバージョン」と書かれたリンク(又はリンクの目的を適切に表した他のリンクテキスト)がある。このリンク先は、宣言のレベルでWCAGに適合している代替版のページである。

検証

チェックポイント
  1. 宣言した適合レベルでWCAGに適合していないページを特定する。

  2. そのページには、適合している代替版へのリンクがある。

  3. 代替版が、オリジナルページの適合している代替版であり、かつ要求された適合レベルでWCAG2.0に適合している。

判定基準
  • 2.及び3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G138: 色の手がかりを用いる際は、必ずセマンティックなマークアップを使用する

適用(対象)

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

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

解説

この達成方法の目的は、色とセマンティックなマークアップを組み合わせて、情報を伝達することである。ほとんどの利用者はコンテンツをすばやく読み取り、色を用いて伝達された情報をコンテンツから見つけることができる。色を見ることができない利用者に対しては、セマンティックなマークアップによって異なるタイプの手がかりを提供することができる。それによって、ユーザエージェントは、たとえば、異なるタイプの構造に対しては異なる視覚的な表現を用いる、又は聴覚的な表現において異なる音声や音の高さを用いることによって、その意味を利用者に対して知覚可能にすることができるようになる。

ほとんどのユーザエージェントは、セマンティックなマークアップを用いて指定されたテキストを視覚的に区別する。支援技術の中には、適切なセマンティックマークアップを用いて制作されたコンテンツの特徴を定めるメカニズムを提供しているものもある。

事例

事例 1: :必須のフォーム項目に対して、色と強調を用いる

HTMLのフォームにいくつかの必須項目がある。必須項目のラベルは赤で表示されている。加えて、各ラベルのテキストは強い強調を示すためにstrong要素でマークアップされている。フォーム入力の説明文には、「すべての必須項目は赤で表示されており、強調されている」とあり、事例が添えられている。

参考リソース

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

検証

チェックポイント

情報を伝達するために色の違いが使用されているコンテンツに対して:

  1. セマンティックなマークアップを通して同じ情報が入手可能である。

判定基準
  • 1.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G139: 利用者がエラー箇所に移動できるメカニズムを作成する

適用(対象)

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

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

解説

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

事例

事例 1: サーバーサイドのエラーチェック

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

事例 2: ポップアップを用いたクライアントサイドのエラーチェック

利用者がフォーム項目に無効なデータを入力して、そのフォームを送信しようとする。クライアントサイドのスクリプトがエラーを検出し、送信をキャンセルした上で、そのフォームにエラーを説明するテキストとエラーのある項目へのリンクを表示する。また、このスクリプトは、問題のある項目のラベルを変更して、それを強調する。

事例 3: ポップアップを用いないクライアントサイドのエラーチェック

利用者がフォームを送信しようとした時、新たなページに遷移させる代わりに、スクリプトが自動的に「エラーが発生しました」というテキストにフォーカスする。エラーを説明するメッセージリストにリンクし、一つ一つの項目がエラー箇所にリンクをする。また、エラー箇所からエラーメッセージリストへのリンクも設置されている。このプロセスが必要な限り繰り返される。

検証

チェックポイント
  1. 故意に必須項目を空白にし、インプットエラーを他の項目に作った状態でフォームを送信する。

  2. 空白になっている必須項目が特定できるテキストメッセージが提供されている。

  3. インプットエラーの項目が特定できるテキストメッセージが提供されている。

  4. 必須項目が未入力であるというメッセージから、対応するそれぞれの入力欄へのリンクがある。

  5. エラーメッセージからエラーリストへのリンクがある。

注記: 達成基準3.3.2では、インプットエラーが検知され、修正の示唆が既知であり、セキュリティ又はコンテンツの目的が脅かされることなく修正の示唆が提供できる場合、利用者に修正の示唆を提供するよう求めている。

判定基準
  • 2. を満たしている場合、4. を満たしている。

  • 2. を満たしている場合、5. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G140: 情報と構造を表現から分離して、異なる表現を可能にする

適用(対象)

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

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

解説

この達成方法の目的は、表現的なエンコーディングからコンテンツの構造的なエンコーディングを論理的に分離することによって、支援技術のコンテンツとのインタラクションを容易にすることである。構造的なエンコーディングとは、見出し、段落、リスト、テーブルなどの要素を指定することであり、そういった目的のために用意されたウェブコンテンツ技術の機能を使用することによって行われる。一方、表現的なエンコーディングとは、書体、色、サイズ、位置、ボーダーのような書式効果の指定であり、ウェブコンテンツ技術の機能によってもサポートされている。

表現的な特性は視覚的に構造を暗示する、つまり利用者は用いられている書式設定の慣例から、見出し、段落、リストなどを判断できる。その一方で、これらの特性は、支援技術によるそのページとの効果的なインタラクションに十分なほど曖昧さのないように構造をエンコードしているわけではない。分離した構造、機能そして表現のレイヤーを提供することにより、書式設定によって暗示された意味を構造のレイヤーを通してプログラムが解釈できるようになる。

この達成方法を用いることによって、ユーザエージェントでは次のことが可能になる:

  • セクションの並び替え、又はセクションのリストやリンクのリストの生成のように、コンテンツの既存の構造をベースにした意味ある構造の変換を実行する。

  • 表現的な情報のみに基づいて支援技術が決定できない、構造上の特徴に基づいたコンテンツとのインタラクションをサポートする。たとえば、リスト項目の数を示す、又はリストの終了位置までスキップすることによって、リストとの特別なインタラクションを提供することは望ましいかもしれないが、これが可能なのはリストの構造がリストの表現に加えてコード化されている場合のみである。

  • 構造の特性に付随した代替の表現ルールを代用することによって、コンテンツの表現を改良する。

事例

事例 1: : CSS付きのHTML

HTMLドキュメントは、段落、リスト、見出しなどHTMLの構造特性を用いていて、書体の変更、レイアウトのヒントなどのような表現的な特性を用いることを避けている。そして、構造的なプロパティに基づいてドキュメントをフォーマットするために、CSSが用いられている。HTMLにおいてよく考えて設計されたclass属性は、必要に応じて構造的なマークアップの意味を拡張し、より柔軟なフォーマットをCSSによって可能にする。支援技術は、CSSを代用又は拡張して表現を改良する、もしくはCSSを無視して構造的なエンコーディングと直接やりとりをする。

事例 2: :タグ付きPDF

PDF文書は、書式設定情報が組み込まれているコンテンツでほとんど成り立っている。構造に関する情報は、XMLのようなタグを使用しているドキュメントの別セクションの中で提供されており、これは「タグ付きPDF」と呼ばれている。それらのタグの中にある情報は、支援技術が意味のある構造の変換に用いる(例えば、セクションのリストを生成する)ため、又は構造的な特徴に基づいたコンテンツとのインタラクションをサポートする(例えば、フォームの先頭にジャンプする)ために使用可能である。

検証

チェックポイント
  1. ドキュメントのコードを調べる。

  2. 構造的な情報と機能性が明白に提供され、表象的な情報から論理的に分離されている。

判定基準
  • 2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G141: 見出しを用いてウェブページを構造化する

適用(対象)

セクションで構成されたコンテンツのあるウェブページ

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

解説

この達成方法の目的は、それぞれのセクションにそれを識別できる見出しがついているようにすることである。達成基準1.3.1では見出しがプログラムで解釈可能な方法でマークアップされていることを要求している。

HTMLにおいては、これは見出し要素(h1, h2, h3, h4, h5, h6)によって実現されうる。これによりユーザエージェントは自動的にセクションの見出しを識別できる。他のウェブコンテンツ技術では、また異なる方法で見出しを識別する。ページ内の移動と文書の全体的構造の理解を助けるには、コンテンツ制作者は見出しを適切に入れ子にするべきである(たとえばh1にはh2が続き、h2にはh2かh3が続き、h3にはh3またはh4が続き……といったように)。

事例

事例 1: HTMLのページを構造化するために用いられた見出し

ある調理法を紹介するページでは、h1要素により全体とタイトルを示し、h2要素で大項目としてサラダ油による調理とバターによる調理を示し、h3要素で油による調理の詳細なサブセクションを示している。

コード例:


<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>調理法</title>
</head>
<body>
<h1>調理法</h1>
... ここにはテキストが入る ...
<h2>サラダ油による調理</h2>
... セクションのテキストが入る ...
<h3>ソテー</h3>
....
<h3>油揚げ</h3>
<h2>バターによる調理</h2>
... セクションのテキストが入る ...
</body>
</html>

参考リソース

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

検証

チェックポイント
  1. ページの内容がセクションに分けられている。

  2. それぞれのセクションに見出しがある。

判定基準
  • 2. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G142: ズーム機能をサポートする一般に入手可能なユーザエージェントのあるウェブコンテンツ技術を使用する

適用(対象)

ズーム機能を提供するユーザエージェントのある全てのウェブコンテンツ技術

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

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

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

解説

この達成方法の目的は、ズーム機能でテキストサイズを変更するユーザエージェントによってサポートされたウェブ技術を使用することによって、均一にコンテンツを拡大・縮小できることを保障することである。

内容を均一(すなわち、内容へズームする)に拡大・縮小できるユーザエージェントによってサポートされたウェブコンテンツ技術で制作されたコンテンツは、この達成基準を満たす。 この達成方法は、完全にユーザエージェントの機能に依存するため、さまざまなユーザエージェントを用いて検証することは重要である。

この達成方法では、ズーム機能を用いてもページ上の全ての空間的な関係が保持され、全ての機能が継続して利用可能である必要がある。

事例

(今のところ、なし。)

検証

チェックポイント
  1. ユーザエージェントでコンテンツを表示させる。

  2. そのコンテンツを200%に拡大する。

  3. 全てのコンテンツと機能が利用可能である。

判定基準
  • 3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G143: 代替テキストを提供して、CAPTCHA の目的を説明する

適用(対象)

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

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

解説

この達成方法の目的は、非テキストコンテンツを特定する代替テキストを介して情報を提供することである。これは、CAPTCHAのテストが、ぼやけた画像又は音声ファイルで提示されるテキストを入力するよう利用者に求めることがしばしばあるためである。この代替テキストによって、利用者は、CAPTCHAがタスクの完了を要求するもので、またそれがどのようなタスクであるかを理解できるようになる。

CAPTCHAの代替版がある際には、代替テキストには、その代替版を見つける方法についての説明を含めるべきである。

事例

検証

チェックポイント
  1. CAPTCHAを取り除く、非表示にする、又は覆い隠す。

  2. CAPTCHAを代替テキストに置き換える。

  3. 代替テキストがCAPTCHAの目的を説明している。

判定基準
  • 3. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G144: 同じ目的を果たす、異なる感覚モダリティを用いたもう一つの CAPTCHA がウェブページにあることを確認する

適用(対象)

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

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

解説

この達成方法の目的は、障害のある利用者がCAPTCHAのタスクを完了できないという事態を減らすことである。異なるモダリティを用いた代替のCAPTCHAを提供することによって、利用者がいずれかのCAPTCHAによりタスクを完了できる可能性が高まる。

事例

検証

チェックポイント

ウェブページにあるCAPTCHAに対して:

  1. ウェブページに、同じ目的を果たす、異なるモダリティを用いたCAPTCHAがもう一つ提供されている。

判定基準
  • 1. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G145: テキスト(及び画像化された文字)とその背景の間に、少なくとも 3:1 以上のコントラスト比をもたせる

適用(対象)

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

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

解説

この達成方法の目的は、利用者が背景の上にあるテキストを読めるようにすることである。この達成方法は、18pt(太字ではない:日本語の場合は22pt)以上と14pt(太字:日本語の場合は18pt)以上のテキストに対しては、少なくとも3:1以上のコントラスト比を要求している。

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

もし背景が無地の色(または真っ黒、真っ白)の場合、各テキストの文字と背景との間に3:1のコントラスト比を持たせることで、大きなサイズのテキストのコントラスト比を維持することができる。

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

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

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

事例

  • 黒い背景を選ぶことによって、企業ロゴに合った明るい色の文字を使うことができる。

    大きなサイズのテキストが大学のキャンパスの写真の上に書かれている。幅広いさまざまな色や暗さが写真に現れているため、テキストの下のエリアに白いもやをかけ、写真を強くかすませることで、一番暗い所でも写真の上に書かれている黒いテキストとの3:1のコントラスト比を維持するのに十分な明るさとしている。

参考リソース

(今のところ、なし。)

検証

チェックポイント
  1. 以下の公式を用いて、各文字(すべて同一ではない限り)の相対輝度を測る:

    • 色の相対輝度 L = 0.2126 * R + 0.7152 * G + 0.0722 * B と定義されている。この場合のR, G 及び B は:

      • RsRGB <= 0.03928 の場合:R = RsRGB/12.92、それ以外の場合: R = ((RsRGB+0.055)/1.055) ^ 2.4

      • GsRGB <= 0.03928 の場合:G = GsRGB/12.92、それ以外の場合:G = ((GsRGB+0.055)/1.055) ^ 2.4

      • BsRGB <= 0.03928 の場合:B = BsRGB/12.92、それ以外の場合:B = ((BsRGB+0.055)/1.055) ^ 2.4

      注記: また、RsRGB, GsRGB, 及び BsRGBは以下のように定義される:

      • RsRGB = R8bit/255

      • GsRGB = G8bit/255

      • BsRGB = B8bit/255

      注記: "^"記号は指数演算子である。

    注記: エイリアス文字では文字の端から2ピクセルの部分の相対輝度の値を使用する。

  2. 同じ公式を用いて、文字のすぐ隣の背景のピクセルの相対輝度を測る。

  3. 次の公式を用いて、コントラスト比を算出する。

    • (L1 + 0.05) / (L2 + 0.05)

      • L1は前景または背景色の明るい方の相対輝度である。及び、

      • L2は前景または背景色の暗い方の相対輝度である。

  4. コントラスト比が3:1と同じ、又はそれ以上である。【訳注:この計算式を用いているチェックツールで、コントラスト比が3:1以上であることを確認すればよい。】

判定基準
  • 4.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G146: リキッドレイアウトを使用する

適用(対象)

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

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

解説

この達成方法の目的は、表示領域幅の広狭に順応するレイアウト手法を用いることで、横スクロールバーが挿入されることなしに、コンテンツを表示できるようにすることである。オンスクリーン・ディスプレイ【訳注:ディスプレイの本体側面などに調節用のつまみがついているのではなく、画面上で各種設定を行うディスプレイ】に対応できるように、必要に応じてテキストサイズが変更できること、テキストを流し込み直せることの両方が可能なレイアウト領域を、リキッドレイアウトによって定義する。したがって、きっちりと決まったレイアウトとはならないが、各要素の関係と描画の順序は同じままである。さまざまなデバイスで問題なく表示できたり、通常とは異なるフォントサイズに設定変更している利用者に対するデザイン制作という面で、リキッドレイアウトは効果的な手法である。

リキッドレイアウトの基本原則は次のとおりである。

  1. レイアウト領域を、テキストに応じてサイズが変わるユニットを利用して定義する。つまり、テキストの拡大縮小と同じように、レイアウト領域が広まったり狭まったりする。

  2. レイアウト領域を、フロートボックスを隣り合わせで横に並べたように配置する。つまり、パラグラフの中の各単語とほぼ同じような方法で、必要に応じて行送りされる。

複雑なリキッドレイアウトの実現には、入れ子にしたレイアウト領域、つまり大きな領域の中に部分ごとの複数の領域を入れ込む方法を利用する場合がある。単純なリキッドレイアウトであっても、テキストサイズの違いに関わらず見た目のよさを損なわないようにデザインを工夫する必要があるとはいえ、十分に計画したリキッドレイアウトは最も効果的なページデザインとなるだろう。

事例

事例 1: HTMLとCSSでの単純なリキッドレイアウト

以下は、リキッドレイアウトの実現にHTMLとCSSを利用した、かなり単純な事例である。3つの列はテキストサイズが変わるのと同じようにサイズ調整される。もし全ての列を足した幅が、3つの列で利用できる幅の合計を超えてしまった場合、最後の列は前の列の横に置かれるのではなく、下に送られる。列に含まれるテキストの中で最も長い単語が列の幅におさまっている限り、フォントサイズを大きくすることができ、ブラウザの横スクロールバーへの影響はない。この事例では列の幅指定にパーセントを利用しており、「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>単純なリキッドレイアウトの例</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の例</h1>
   <h2>3つの列に含まれるテキスト</h2>
      <div title="1列目" class="column">
        <h3>Block 1</h3>
        <p> この達成方法の目的は、表示領域幅の広狭に順応するレイアウト手法を
            用いることで、横スクロールバーが挿入されることなしに、コンテンツ
            を表示できるようにすることである。
        </p>
      </div>

      <div title="2列目" class="column">
        <h3>Block 2</h3>
        <p> これはとても簡単な例であり、テキストサイズの変化に順応するページ
            レイアウトである。
        </p>
      </div>

      <div title="3列目" class="column">
      <h3>Block 3</h3>
        <p> より複雑なページレイアウトに関する達成方法については、以下の参考
            リソースを参照のこと。
        </p>
      </div>

      <p id="footer">Footer text</p>
</body>
</html>

参考リソース

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

検証

チェックポイント
  1. ユーザエージェントでコンテンツを表示する。

  2. テキストサイズを200%に拡大する。

  3. ブラウザの横スクロールバーが表示されることなしに、すべてのコンテンツが表示され、すべての機能が利用できるか確認する。

判定基準
  • 3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G148: 背景色及びテキストの色を指定せず、その初期設定を変更するウェブコンテンツ技術の機能を使用しない

適用(対象)

テキストと背景の色が別々に指定されている、及びブラウザが初期設定の色を制御できるあらゆるウェブコンテンツ技術

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

解説

この達成方法の目的は、利用者が背景の上にあるテキストを読めるようにすることである。この達成方法では、コンテンツ制作者は単純にテキストの色と背景色を指定しないことで、コントラストに関する処置を行わない。その結果、両方の色はユーザエージェントによって完全に決定される。

視覚障害を持つ人々の中には、彼らが見づらい何色かを上書きするようユーザエージェントを設定している人がいる。この達成方法は、ユーザエージェントとウェブサイトがコンフリクトを起こし、結果として文字色と背景色が同じ色になってしまうことで、ブラウザや支援技術で独自の色設定をしている利用者にとって不可視の状態になるという場合を避けるためのものである。

事例

事例 1

事例 1:コンテンツ制作者はテキストの色も背景も指定していない。CSSも使用していない。その結果、利用者は彼らにとって都合のよい色とコントラストを提供するブラウザの初期設定を利用可能となる。

参考リソース

検証

チェックポイント
  1. テキストの色を指定できる箇所全てを見る。

  2. テキストの色が指定されていない。

  3. 背景として用いられている背景色又は画像が指定されている箇所全てを見る。

  4. 背景として用いられている背景色又は画像が指定されていない。

判定基準
  • 2.と4.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G149: フォーカスを受け取った際に、ユーザエージェントによって強調されるユーザインタフェースコンポーネントを使用する

適用(対象)

ユーザエージェントによって提供されるフォーカスのハイライトを用いる全てのウェブコンテンツ技術

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

解説

この達成方法の目的は、ユーザエージェントのサポートにより、利用者が、フォーカス可能なコンポーネントを視覚的に識別できるようにすることである。フォーカスを受け取った際に、何らかの方法で標準的なコンポーネントを強調することはユーザエージェントでは一般的である。UAAGのチェックポイント 10.2「選択状態の強調、コンテンツのフォーカス、活性の要素、訪問済みリンク」(英語)を満たす場合、UAAGに適合したユーザエージェントでは標準的なコンポーネントは強調される。ユーザエージェントがサポートしている標準的なコントロールをウェブ制作者が使用すれば、利用者は、フォーカスの置かれている場所を標準的で予測可能な方法で知ることができる。

事例

  • HTML のテキスト入力フィールドがフォーカスを受け取ったとき、ブラウザーが、テキストフィールドの中の入力箇所に点滅する垂直なバーを表示する。

  • HTML のリンクがフォーカスを受け取ったとき、フォーカスを強調する長方形の点線で囲まれる。

参考リソース

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

検証

チェックポイント

ウェブページ上のフォーカス可能な各コンポーネントに対して:

  1. そのコントロールにフォーカスを設定する。

  2. 何らかの方法でユーザエージェントがコントロールをハイライトしている。

判定基準
  • 2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G150: ライブの音声しか含まないコンテンツに対して、テキストベースの代替コンテンツを提供する

適用(対象)

ライブの音声しか含まない情報を提示する全てのウェブコンテンツ技術

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

解説

この達成方法の目的は、耳の聞こえない利用者がリアルタイムの音声の放送にアクセスできるようにすることである。間違いを修正する、聞きなおす、又は言葉が正しく再現できているかを誰かに確認する時間がほとんどないため、リアルタイムの代替物を制作することは困難である。また、音声の放送が非常に速く流れている場合は、情報を簡略化したり、言い換えたりすることも困難である。

リアルタイムのタイピングによるテキスト入力技術には、速記及び高速タイピングがある。復唱して音声認識入力する方法(話を聞き取って、注意深く復唱し、復唱する話者の音声認識トレーニングをしたコンピュータで入力する)は、現在では電話伝送サービスに使用されており、将来的にはキャプション制作に使用されるかもしれない。いずれは修正機能付きの音声認識入力も可能になるだろう。

事例

検証

チェックポイント
  1. 代替テキストがリアルタイムで伝達されるように手順とポリシーが整っている。

  2. 代替テキストが提供されているかどうかをランダムにチェックすると、手順とポリシーの通りである。

判定基準
  • 1. 及び 2. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G151: 予め用意されたスピーチ原稿のトランスクリプト、又は台本通りのコンテンツの場合には台本へのリンクを提供する

適用(対象)

ライブの音声しか含まない情報を提示する全てのウェブコンテンツ技術

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

解説

この達成方法の目的は、トランスクリプト(書き起こしたテキスト)又はライブの音声コンテンツが予め用意された台本に従っている場合は台本を提供することである。台本は予め用意されているので、ライブの書き起こしより正確で完全である。台本は音声の再生には同期しないこともあるが、この達成方法を用いるには、ライブの音声は台本から逸脱するべきではない。

この達成方法をもちいることによって、トランスクリプト又は台本へのリンクが提供され、WCAG 2.0に適合する。そのトランスクリプト又は台本は、同じウェブページ上にあってもよいし、別のURIにあってもよい。

事例

  • フリンジ・シアター(小劇場)のグループによるライブのラジオ劇がウェブで放送されている。俳優は用意された台本に概ね従っており、演目のための予算も少ないので、プロデューサーは(劇作家の承諾を得て)HTML でその劇の台本へのリンクを設けた。

  • 政府の一人がウェブ上で重要な政策のスピーチを行う。スピーチが始まると、スピーチのトランスクリプトがウェブサイト上から入手できるようになる。

参考リソース

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

検証

チェックポイント
  1. 台本又はトランスクリプトに直接遷移するリンクがある。

  2. ライブの音声が台本に従っている。

  3. 代替版が別のページにある場合、その版に利用者がたどり着けるようにリンクが設けられている。

判定基準
  • 上記全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G152: 数回のループ後(5 秒以内)に停止するように、アニメーション GIF を設定する

適用(対象)

アニメーションGIF (GIF89a)をサポートするあらゆるウェブコンテンツ技術

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

解説

この達成方法の目的は、アニメーションGIF画像が5秒以内に点滅を停止するようにすることである。アニメーションGIF画像を制作する際には3つの側面があり、それらが作用しあって画像が点滅する(あるいは動く)時間を決定している:

  • アニメーション画像に含まれるフレーム数:これらは連続するアニメーションの中では別々の画像である

  • フレームレート:それぞれの画像を表示する時間

  • 繰り返しの回数:アニメーション全体を再生させる回数

一番単純な場合では、アニメーションの再生時間は、フレーム数×フレームレート×繰り返し回数である。例えば、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秒以内に画像の点滅を終了させるためには、3つの変数のうちのいずれかを調整しなければならない。最も一般的には、繰り返しの回数を5秒÷フレーム数×フレームレート(又は5秒÷フレームレートの合計)に設定し、5秒以内に画像を終了させるために、最も近い整数になるようにこの数字の端数を切り捨てる。一つ上の整数に切り上げてはならない。

繰り返しが1回で5秒を超える場合は、別の要素のうちの一つを調整しなければならない。画像の中のフレーム数を減らす、又はフレームレートを増やす。フレームレートを増やす場合は、変更後の画像が一般閃光閾値又は赤色閃光閾値を超えないという要求事項に不適合にならないように留意すること。これは大きな画像では特に重要であるので注意すること。

事例

検証

チェックポイント
  1. アニメーションGIFを表示させ再生時間を調べる。

  2. 別の方法として、画像編集ソフトを使用してフレーム数、フレームレート及び繰り返し回数を確認する。フレーム数×フレームレート×繰り返し回数を計算する。フレームレートが一つでない場合は、フレームレートの合計×繰り返し回数を計算する。

  3. アニメーションの再生時間が5秒以内である。

判定基準
  • 3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G153: テキストを読みやすくする

適用(対象)

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

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

解説

この達成方法の目的は、ウェブページ上のテキストを読むのが難しくないようにすることである。単語や文を解読することが困難になるような障害のある利用者は、複雑なテキストを読んで理解するのを苦手とすることが多い。そのテキストが前期中等教育レベルを超えた読解能力を必要としないならば、補足や代替版は必要ない。

テキストの複雑さを軽減する方法【訳注:以下は英語における留意点であると考えられ、日本語の場合には当てはまらないものも含まれているかもしれません。】:

  • 段落ごとに一つのトピックまたはサブトピックのみを展開する

  • コンテンツの目的に矛盾しない範囲でもっとも単純な構文を用いる。たとえば、英語のもっとも単純な構文は「John hit the ball」、「The Web site conforms to WCAG 2.0」のように「主語、動詞、目的語」からなる。

  • 文の長さは、前期中等教育レベルで典型的に許される範囲とする。(注記:英語では25ワードである)

  • 長い文は二つに分割することを検討する。

  • 一つの文に三つ以上の接続詞を用いないようにする。

  • テキスト中のフレーズ、文、段落、セクション間の論理的関係を明確にする。

  • 一般の人にとって意味が明らかでないような専門的な職業語や俗語等の言い回しを避ける。

  • 長い又は馴染みのない言い回しは、より短く一般的なものに置き換える。

  • 取り除いても文章の意味が変わらないような冗長な単語を取り除く。

  • 単独の名詞または短い名詞句を使用する。

  • 文の意味を変えずにより広く使われる言い回しに置き換えられるような単語やフレーズを取り除く。

  • いくつもの単語やフレーズからなる複数の項目を、コンマで区切って一つの段落内に並べることは避け、番号なし/番号付きリストを使用する。

  • 代名詞による参照や文中の他の箇所への参照は明確なものにする。

  • 英語および他の一部の欧米系言語で書かれる文書では、受動態を使う特別な理由がない限り、能動態を用いる。たいていの場合、能動態の文章は受動態よりも短く、理解しやすい。

  • 動詞の時制に一貫性を持たせる。

  • 名前やラベルに一貫性を持たせる。

事例

検証

チェックポイント
  1. 文章の読みやすさ(リーダビリティ:readability)を検査する。

  2. そのテキストが要求する読解能力が、前期中等教育レベルを超えていない。

判定基準
  • 2. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G155: 送信ボタンに加えてチェックボックスを提供する

適用(対象)

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

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

解説

この達成方法の目的は、利用者が自身の入力した内容を確認し、送信の準備ができたことを示すために選択しなければならないチェックボックスを提供することである。これは、後で入力エラーが発見されてもやり直しができない、または実行の結果データが削除されるような性質の処理においては重要である。コンテンツ制作者は、ページが読み込まれた時には選択されていないチェックボックスを配置し、「入力内容に間違いはなく、送信準備ができました」、あるいは「このデータの削除に同意します」といったラベルを付加する。このチェックボックスは、利用者が送信の過程で気づきやすいように、送信ボタンの近くに配置するべきである。そのフォームが送信された時にチェックボックスが選択されていない場合は、入力を受け付けず、利用者に対して入力内容を確認の上、チェックボックスを選択し、再送信するように促す。チェックボックスが選択されているときだけ、送信された内容を受け付け、処理を行う。

このチェックボックスを配置することで、フォームを誤って送信してしまった場合の影響を抑制すると同時に、利用者に対して入力内容が正確であることを確認するように促すことができる。この方法は、単に送信ボタンに「入力内容に誤りがなければ送信」というようなラベルを付加するよりも安全な方法である。送信ボタンとは別のコントロールとしてチェックボックスを提供することで、処理を続行するために利用者はチェックボックスの選択と送信ボタンの押下の両方をしなければならず、結果として入力内容をサイド確認することにつながる。したがって、これは送信内容を確定する前に、入力内容を見直し、正確さを確認し、訂正するための仕組みである。

注記: 利用者がチェックボックスを選択せずに送信した場合、再送信のためのフォームで、これまでに入力した情報を再入力する必要がないようにしなければならない。

事例

検証

チェックポイント

利用者の入力を求めるようなページで、やり直しができない処理が発生する場合:

  1. 送信ボタンに加えて、入力や操作に対する利用者の確認が必要であることを示すチェックボックスが提供されている。

  2. フォームが送信されたときにチェックボックスが選択されていない場合は、入力は受け付けられず、利用者に対して入力内容の確認をした上で、チェックボックスを選択し、再送信するようになっていることを確認する。

判定基準
  • 1. 及び 2. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G156: 一般に入手可能なユーザエージェントで、テキストのブロックの前景及び背景を変更できるウェブコンテンツ技術を使用する

適用(対象)

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

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

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

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

解説

認知障害のある利用者は、ウェブページのコンテンツをうまく理解するために、前景のテキストと背景を特定の色の組み合わせを必要としていることがある。一般に利用されるブラウザの大部分が、ブラウザ内部の機能として、色設定を変更するオプションを提供している。この機能によって、コンテンツ制作者が指定した前景色や背景色を、利用者が選択した色で上書きできる。

この達成基準を満たすためには、コンテンツ制作者はこのようなコントロールを備えるブラウザでウェブページが利用できるようにデザインし、この機能を無効にするような実装を行なってはならない。

ページ上の全てのテキストの前景色と背景色を上書きすると、ページのグループ化や組織化に関する視覚的な手がかりが失われ、かえって理解や利用が困難になる恐れがある。ページ上の各領域の境界を示すのに背景色を用いている場合、この達成方法が適切ではない可能性がある。背景色をページ上の各領域の境界を示すのに用いているならば、「C23: メインコンテンツのテキスト及び背景の色を指定せず、バナー、特集記事及びナビゲーションなどのようにメインではないコンテンツのテキスト及び背景の色を CSS で指定する (CSS) 」に基づき、ページの視覚的な構造は保ちつつ、利用者が主要なテキストの色をコントロールできるようにするとよい。

事例

  • 前景色と背景色の指定のために、HTML と CSS を用いてデザインしているウェブページがある。利用者はInternet Explorer 7 で自分の望む色に設定し、選択した前景色と背景色でコンテンツを見ることができる。

  • HTML と CSS を用いてデザインしているウェブページがある。さまざまなブラウザでどのように色を設定するかを説明したページへのリンクを設置している。

参考リソース

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

検証

チェックポイント
  1. HTML コンテンツの色を利用者が変更できるブラウザで、ウェブページを開く。

  2. ブラウザ設定で、コンテンツに指定された色とは異なる前景色と背景色に変更する。

  3. ページに戻ると、ブラウザで設定した別の前景色と背景色が、コンテンツに指定された色を上書きしている。

判定基準
  • 3. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G157: ライブの音声キャプションサービスをウェブページに組み込む

適用(対象)

ライブの音声しか含まない情報を提示する全てのウェブコンテンツ技術

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

解説

この達成方法の目的は、ライブの音声コンテンツのテキスト版を提供するために、リアルタイムのキャプションサービスを用いることである。このようなサービスは、何が話されているかを聞き取り、専用キーボードによりわずかな遅れでテキスト入力する訓練を受けた人間のオペレーターによって行われる。彼らは非常に忠実にライブのイベントを捉えることができ、そのイベントを理解する上で重要な発話以外の音声についても注記を入れることができる。キャプションのテキストを含むビューポートは、ライブの音声コンテンツと同一のウェブページ上で利用できる。

事例

  • インターネットラジオ局で、ウェブページ上にニュースサービスのためのビューポートがある。ライブのニュースのレポート、特に緊急レポートの場合、リアルタイムのキャプションサービスによりテキストが書き起こされてビューポートに表示される。

  • 会議又はスクリーン・シェアリング・サービスに、口頭での発表のリアルタイムの書き起こしを流すウィンドウがある。これは、遠隔リレー式音声電話会議キャプションサービスを予め手配しておくことで実現している。ライブのテキスト用に別のウィンドウを使用すると重大なユーザビリティ上の障害となりうるので、オンラインウェブ会議又はスクリーン・シェアリング・サービスではこのような使われ方をすることを想定してデザインする必要がある。

  • 定例の音声会議では、順番に発言できるように挙手機能ユーティリティを使用している。オンライン・リレー式音声電話会議キャプションサービスと共にこの製品を利用しやすくするために、発言順のユーティリティは、狭いビューポートの中で全ての機能を操作できるようにデザインされている。より高度な利用のために、ウェブサイトは1ページの中に両方のビューポートを表示するように制作されている。

参考リソース

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

検証

チェックポイント
  1. ライブの音声コンテンツと関連付けられたビューポートがウェブページ上にある。

  2. ライブの音声コンテンツのテキストが、30秒未満の遅れでビューポートに表示される。

判定基準
  • 上記全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G158: 時間の経過に伴って変化するメディアの音声しか含まないコンテンツに対して代替コンテンツを提供する

適用(対象)

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

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

解説

この達成方法の目的は、音声しか含まないプレゼンテーションで提示する情報に対して、アクセシブルな代替コンテンツを提供することである。

音声しか含まないプレゼンテーションにおいては、会話や音(自然なものと人工的なものの両方)を含め、情報はさまざまな方法で提示される。同じ情報をアクセシブルな形式で提示するために、この達成方法では、収録済の音声しか含まないコンテンツと同じストーリーを伝えて同じ情報を提示するドキュメントを作成する。この達成方法において、そのドキュメントはコンテンツの長い説明としての役割を果たし、重要な会話内容のすべてとストーリーの一部である背景音の説明を含んでいる。

音声しか含まないコンテンツを制作する際に台本を用いている場合には、それを手始めにすることができる。しかし、制作及び編集過程において、コンテンツの内容が台本からいくぶん変わってしまうことがよくある。この達成方法で台本を用いる際は、もともとの台本を音声のプレゼンテーションの最終版の会話内容及び実際の内容に合わせて修正することになる。

事例

  • ソフトウェアの最新のリリースにおける新機能の説明をしているポッドキャストがある。二人の話者が、新機能と更新された機能について話をしながら、どのように使うのかを説明している。話者の一人は、収録前に議論のアウトラインを整理するために用意した質問のリストを使っている。そして収録終了後、そのアウトラインを編集して、会話内容に合わせて言葉を補うなどする。そうして出来上がったトランスクリプトは、音声しか含まないファイルと一緒に、話者のウェブサイトで公開されている。音声しか含まないコンテンツを特定する代替テキストには、「エピソード 42: Zp バージョン 12(テキストのトランスクリプトあり)」と書かれていて、そのトランスクリプトへのリンクが、音声しか含まないコンテンツのすぐ後に提供されている。

参考リソース

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

検証

チェックポイント
  1. 時間の経過に伴って変化するメディアに対する代替コンテンツを参照しながら、音声しか含まないコンテンツを閲覧する。

  2. トランスクリプト内の会話内容が、音声しか含まないプレゼンテーションで提示されている会話内容及び情報と一致している。

  3. 音声に複数の話者がいる場合、すべての会話内容に対してトランスクリプトで話者が誰なのかを示している。

  4. 次のうち少なくとも一つを満たしている:

    1. トランスクリプト自体が、音声しか含まないコンテンツに対する代替テキストからプログラムで解釈可能である。

    2. トランスクリプトが、音声しか含まないコンテンツに対するプログラムで解釈可能な代替テキストから参照されている。

  5. 代替版が別ページにある場合、利用者が他のバージョンへ移動できるリンクが提供されている。

判定基準
  • 上記のチェックポイント全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G159: 時間の経過に伴って変化するメディアの映像しか含まないコンテンツに対して代替コンテンツを提供する

適用(対象)

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

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

解説

この達成方法の目的は、映像しか含まないプレゼンテーションで提示する情報に対して、アクセシブルな代替コンテンツを提供することである。

映像しか含まないプレゼンテーションにおいては、アニメーション、テキスト又はグラフィック、また状況及び背景、人物や動物の動き及び表情などを含め、情報はさまざまな方法で提示される。同じ情報をアクセシブルな形式で提示するために、この達成方法では、収録済の映像しか含まないコンテンツと同じストーリーを伝えて同じ情報を提示するドキュメントを作成する。この達成方法において、そのドキュメントはコンテンツの長い説明としての役割を果たし、重要な情報のすべてとプレゼンテーションの一部である風景、動き、表情などの説明を含んでいる。

映像しか含まないコンテンツを制作する初めの段階で台本を用いている場合には、それを手始めにすることができる。しかし、制作及び編集過程において、コンテンツの内容が台本からいくぶん変わってしまうことがよくある。この達成方法で台本を用いる際は、もともとの台本を映像しか含まないプレゼンテーションの最終版の内容に合わせて修正する必要がある。

事例

  • 木工品の組み立て方を紹介するアニメーションがある。音声はないが、アニメーションにはプロセス中の各ステップの順番を示す番号があり、矢印と該当箇所の拡大図によってどのように組み立てていくのかが示されている。あわせて、正しく組み立てなかった場合にはどうなるのかを示す短いアニメーションも提供されている。映像しか含まないコンテンツを特定する代替テキストには、「パン入れの組み立て方の映像(テキストによる説明あり)」と書かれていて、映像のテキストによる説明では、その映像にある各ステップの完全なテキストによる説明が提供されている。

参考リソース

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

検証

チェックポイント
  1. 時間の経過に伴って変化するメディアに対する代替コンテンツを参照しながら、映像しか含まないコンテンツを閲覧する。

  2. トランスクリプト内の情報によって、映像しか含まないプレゼンテーションと同じ情報が提供されている。

  3. 映像に複数の登場人物がいる場合、トランスクリプトで説明されている動きに対して、それぞれがどの登場人物によるものかが示されている。

  4. 次のうち少なくとも一つを満たしている:

    1. トランスクリプト自体が、映像しか含まないコンテンツに対する代替テキストからプログラムで解釈可能である。

    2. トランスクリプトが、映像しか含まないコンテンツに対するプログラムで解釈可能な代替テキストから参照されている。

    3. 代替版が別ページにある場合、利用者が他のバージョンへ移動できるリンクが提供されている。

判定基準
  • 上記のチェックポイント全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G160: コンテンツを利用するのに理解が不可欠な情報、アイデア及びプロセスの手話バージョンを提供する

適用(対象)

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

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

解説

聴覚障害や認知障害のある利用者の中には、手話を第一言語としている人がいる。そのような利用者にとっては、文語バージョンよりもページの手話バージョンのほうが理解しやすい可能性がある。この達成方法の目的は、概念やプロセスが記述された難しいテキストについて、手話利用者の理解するのを助ける手話バージョンを提供することである。手話コンテンツはそのテキストに追加で提供する。

手話バージョンは補足コンテンツであるため(また、手話はコンテンツを音声で読み上げる目的のものではないため)、主要なコンテンツとは別の部分で見られる状態にすべきだが、必ずしも同期させる必要はない。同期が有用な場合があるとしても、必須ではない。

手話バージョンをコンテンツの別の部分で利用可能にするために、ビデオをページに直接埋め込んだり、ビデオプレーヤーを別ウィンドウで起動するリンクを含めてもよい。ビデオ表示用の別ページへのリンクによって、手話バージョンを提供することもできる。

手話は、手のひら、腕、肩、頭、顔、唇、舌を使って伝える、三次元の視覚言語である。何が示されているのかを受け手が正しく理解するために、ビデオでは完璧な手話を録画しなければならない。一般的に、手話通訳者は見切れ(ビデオの外に手が出てしまうこと)が発生しない範囲で、できるだけカメラに近づいて手話を行なう。

手話通訳者の見つけ方については、後述の参考リソースの部分に載っている。【訳注:ただし、主に英語圏での情報である。】

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

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

事例

  • あるウェブサイトでは、サポート部門への連絡方法や質問の送信方法を、テキストと同じく手話ビデオでも提供している。

  • あるウェブアプリケーションでは、ヘルプページをテキストと同じく手話でも提供している。

  • ある会社のウェブサイトでは、各製品の技術情報を説明した手話ビデオを提供している。

  • ある宗教団体のウェブサイトは、複数の言語で利用できるようにしてあり、その中にアメリカの手話も含めてある。

参考リソース

検証

チェックポイント
  1. コンテンツを利用するのに理解が不可欠なアイデアやプロセスを説明しているテキストを見出す。

  2. コンテンツの中で、あるいは、コンテンツ内のリンクを通じて、テキストの補足となる手話が利用できる。

  3. 手話による補足が、テキストで説明している概念やプロセスを伝えている。

判定基準
  • 2. 及び 3. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G161: 検索機能を提供して、利用者がコンテンツを見つけるのを手助けする

適用(対象)

フォームを含む全てのウェブコンテンツ技術

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

解説

あなたのウェブページを探す検索機能を提供するのは、コンテンツを見つける方法を利用者に提供するデザインの戦略である。利用者は、ウェブサイトの構造を理解したり、サイト内を見て回ったりする必要なく、特定の単語又は句で検索することでコンテンツの場所を特定することができる。 これは、特に大きいサイトで、より迅速に又はより簡単にコンテンツを見つける方法である。

いくつかの検索企業は、彼らの検索アプリケーションの無償利用をサイトに提供している。検索エンジンはあなた自身のサーバーにインストールして利用できる。いくつかのウェブ・ホスティング企業は、顧客がウェブページに含めることができる検索スクリプトを提供している。また、ほとんどのサービスが、より高度な特徴を持つそれらツールの有償バージョンを提供している。

用語をスペルチェックし、用語の異なった語尾を含み(ステミング)、異なった用語の使用(同義語)を考慮する検索機能を実装すると、検索機能のアクセシビリティはさらに増すだろう。

検索の機能性は、普通は検索ワードのためのテキストフィールド及び検索を開始するためのボタンを含むウェブページの単純なフォーム、又は検索フォームを含むページへのリンクを追加することによって、高めることができる。もちろん、検索フォーム自体もアクセシブルでなければならない。

外部検索の検索エンジンの結果を最適化するのに使用され、また内部検索エンジンもサポートしており、それらをより効果的にする達成方法: キーワード、METAタグ、およびアクセシブルなナビゲーション構造を使用する。検索サイトは、検索のために最適化されたコンテンツをどう作成するかのガイダンスを提供している。例えば、Google Webmaster Guidelines、及びYahoo! Search Content Quality Guidelinesである。

事例

事例 1: ショッピングサイト

あるショッピングサイトは、商品を、婦人服、紳士服、こども服といったいろいろなカテゴリーに分かれて構成されている。これらには、上着、ズボン、靴、アクセサリーといった小分類がある。また、各ページは検索フォームを含んでいて、利用者は、商品を見つけるために商品分類をたどって見ていくよりもむしろ、商品番号又は商品の特徴を検索フィールドに入力することにより、その商品に直接行くことができる。

事例 2: ヘルプセンター

あるヘルプセンターは会社の商品に関する何千ページものヘルプ情報を含んでいる。検索フォームにより、利用者は検索ワードを含む記事を見つけるためにヘルプセンターのページを検索できる。

参考リソース

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

検証

チェックポイント
  1. ウェブページに検索フォーム又は検索ページへのリンクがある。

  2. ウェブページにある検索フォームにテキストを入力する。

  3. 検索を実行する。

  4. 利用者が検索ワードを含むページに辿り着く。

  5. 又は、利用者が検索ワードを含むページへのリンクのリストを含むページに辿り着く。

判定基準
  • 1.を満たしていて、加えて 4.又は 5.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G162: ラベルを配置して、関係性を最大限に予測できるようにする

適用(対象)

フォームをサポートするウェブコンテンツ技術全て

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

解説

フォームのフィールドに対するラベルを、視覚的に利用者が予想しやすい位置に置くと、複雑なフォームを理解したり、特定のフィールドを見つけるのが容易になる。ほとんどのフィールドに対するラベルは、そのフィールドの直前、すなわち、書字方向が左から右の言語の場合、そのフィールドの左か上に、書字方向が右から左の言語の場合、そのフィールドの右か上に置かれる。ラジオボタン及びチェックボックスのためのラベルはそのフィールドの後に置かれる。

これらの配置は自明である。フィールド、ラジオボタン、及びチェックボックスのラベルを置く一般的な(そのために最も予測できる)位置だからである。

入力フィールドはさまざまな長さになることがあるため、ラベルはフィールドの前に置かれる。フィールドの前にそれらを置くことでラベルを整列させることができる。また、ラベルがフィールドの直前にあるため、画面拡大ツール使用時でもラベルの場所を見つけることが容易になり、また、(フィールドの始まりが縦に整列しているとき)縦の列の中でも見つけることができる。最後に、フィールドにデータが入力されているならば、ラベルを読んでから内容を読むほうが、逆の場合よりもデータを理解したりチェックすることが容易になる。

チェックボックス及びラジオボタンは一定の幅を持っているが、それらのラベルは往々にしてそうではない。チェックボックス又はラジオボタンを最初に置くことで、ボタンとラベルの両方を縦に整列させることができる。

事例

事例 1: テキストフィールドの上側のラベル

すぐ上にラベルが配置された二つのテキストフィールド

事例 2: テキストフィールドの左側のラベル

すぐ左側にラベルが配置されたふたつのフィールド.

事例 3: ラジオボタンの右側のラベル

ラジオボタンの右側にラベルが配置されたふたつのラジオボタンを含むフォームのコントロールのグループ

参考リソース

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

検証

チェックポイント

ウェブページの各フォームのフィールドに対して:

  1. フォームのフィールドに目に見えるラベルがある。

  2. フォームのフィールドがチェックボックス又はラジオボタンであれば、ラベルがそのフィールドの直後にある。

  3. フォームのフィールドがチェックボックス又はラジオボタンでなければ、ラベルがそのフィールドの直前にある。

判定基準
  • 全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G163: オフにすることが可能な標準的な発音区別符号を使用する

適用(対象)

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

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

解説

この達成方法の目的は、標準的な発音区別符号をオンにしたりオフにできるメカニズムを利用者に提供することである。

単語の発音を正しく示したり、単語同士の区別に役立つように、多くの言語で発音区別符号が利用されている。一部の言語は、母音、重子音、母音や子音の欠落を示したり、他の目的のために発音区別符号を用いている。発音区別符号がなくてもテキストを読むことはできるが、発音区別符号の追加によって読解可能性(リーダビリティ:Readability)を改善できる。

事例

事例 1

あるハワイ語で書かれたウェブページには、初期状態で発音区別符号が表示されているが、次のような発音区別符号の表示レベルを利用者が選択できるリンクが提供されている:

  • 発音区別符号を表示しない

  • ʻokina(オキナ)の記号(‘)は表示するが、長音記号は表示しない

  • 全ての発音区別符号を表示する

訪問者が好みのレベルを選択すれば、その設定はセッションクッキーに保存される。同じセッションの間、後に見る全てのページはクッキーにアクセスをしつづけ、選択したレベルに合わせて発音区別符号が表示されたり非表示になる。

サーバサイドでは、コンテンツには全ての発音区別符号が含まれている。訪問者が発音区別符号を少なくするか全くない選択肢を選べば、サーバサイドで設定の通りに発音区別符号を置き換えたり取り除いてからページを表示する。

Hawaiian language onlineがその例である。

検証

チェックポイント

語彙の区別のために発音区別符号を利用する言語で作った、あらゆるウェブページについて:

  1. コンテンツの初期状態で発音区別符号を用いている。

  2. 発音区別符号をオンにしたりオフにできるメカニズムがある。

  3. 発音区別符号をオフにするメカニズムによって、発音区別符号が実際に非表示になる。

  4. 発音区別符号をオンオフにするメカニズムによって、発音区別符号が実際に表示される。

判定基準
  • 1. から 4. の全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G164: フォームの送信後に、利用者がそのオンラインでのリクエスト(またはトランザクション)を修正またはキャンセルできる一定の時間を提供する

適用(対象)

フォームを提供する全てのウェブコンテンツ技術

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

解説

この達成方法の目的は、注文を変更又はキャンセルできる猶予期間を提供することによって、利用者が誤った注文をしてしまった際にその内容を変更又はキャンセルできるようにすることである。一般的には、契約又は注文は法的な義務であり、キャンセルすることができない。しかしながら、ウェブサイトにおいては、この機能を提供し、利用者が注文内容を間違えてしまった際には、注文を変更又はキャンセルできるようにすることが可能である。

ウェブコンテンツでは、フォームを送信した後、キャンセル可能期間がどのくらいなのか、及びどのような手続きで注文をキャンセルするかを利用者に伝える必要がある。注文をキャセルする手続きがオンラインでは利用できない場合もあり得る。例えば、ウェブページ上に記載された住所宛に書面による通知が必要な場合である。

フォームを送信した後に、利用者にキャンセル可能期間の長さ及び、注文キャンセルの手続き方法を伝える。注文キャンセルの手続き方法を、キャンセル可能期間と同時に伝えることは、他のメカニズムを使えない利用者に必要で、最善の方法といえる。しかし、必要であれば、複合的な障害に対するアクセシビリティを担保できる場合に限り、他のメカニズムや他のメカニズムとの組み合わせでキャンセル手続きの方法を提供してもよい。その場合は、利用者にフォームを送信する前にオンラインでの注文はキャンセルができないことを警告する。

事例

事例 1: オンラインショッピング

オンラインショッピングのウェブサイトで、24時間以内であれば利用者が購入をキャンセルできるようにしている。そのウェブサイトでは彼らの方針を説明しており、電子メールで利用者に送られる注文確認書の方針の要約も含まれている。24時間以降は購入した物は利用者宛に発送され、キャンセルすることはできない。

事例 2: カスタムオーダー

あるウェブサイトでオーダーメイドのスポーツジャケットを販売している。顧客は生地を選び、身体の寸法を仕立て店に送る。ウェブサイトは注文の変更やキャンセルに対して3日の猶予を与えている。その顧客の寸法に合わせて生地が裁断されると、注文の変更又はキャンセルはできなくなる。そして、会社の方針がウェブサイト上で説明されている。

検証

チェックポイント
  1. 注文のキャンセル又は変更をすることが可能な期間についてウェブページ上に記述がある。

  2. 注文のキャンセル、又は変更のための手続きについてウェブページ上に記述がある。

判定基準
  • 1.及び 2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G165: 視認性に優れた標準のフォーカスインジケータが引き継がれるように、プラットフォーム標準のフォーカスインジケータを使用する

適用(対象)

フォーカス可能な要素を提供する全てのウェブコンテンツ技術

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

解説

この達成方法の目的は、視認性に優れた標準のフォーカスインジケータが引き継がれるように、プラットフォーム標準のフォーカスインジケータを用いることである。OSには標準のフォーカス表示があり、多くのユーザエージェントで利用可能となっている。フォーカスインジケータのデフォルトの描画は常に視認性に優れているわけではなく、ある背景では見づらくなっている。しかしながら、多くのプラットフォームでは、利用者がフォーカスインジケータの描画をカスタマイズすることができる。支援技術では、標準のフォーカスインジケータの外観を変更することもできる。標準のフォーカスインジケータを使っている場合、システム全体に対する見え方の設定はウェブページに引継がれる。例えば、利用者の操作に反応してページの一部分を色付けするといった独自のフォーカスインジケータを表示させる場合、このような設定は引継がれない。通常、支援技術は利用者独自のフォーカスインジケータを見つけることはできない。

事例

事例 1

マイクロソフトウィンドウズのデフォルトのフォーカスインジケータは、フォーカスが当たっている要素の回りに1ピクセルの黒い点線で表示される。暗い背景のページ上では、これは非常に見づらくなる。そのページの制作者がデフォルトを使用し、利用者はウィンドウズ上で明るい色にカスタマイズする。

事例 2

HTMLにおいて、フォーム要素とリンクにはデフォルトでフォーカスが当たるようになっている。さらに、tabindexの属性値が0以上のあらゆる要素はフォーカスを受け取る。フォーカスが当たっている要素はどちらのタイプの場合でも、システムのフォーカスインジケータを使用し、フォーカスインジケータのスタイルについてのプラットフォームの変更を検知する。

検証

チェックポイント
  1. フォーカスインジケータの外観をカスタマイズするには、プラットフォームの機能を使用する。

  2. フォーカスの移動順序に注意しながら、ページ内をキーボード操作でタブ移動する。

  3. 全てのコントロールでフォーカスインジケータが視覚的に認識可能である。

判定基準
  • 3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G166: 重要な映像コンテンツを説明する音声を提供する

適用(対象)

映像コンテンツを実装できる全てのウェブコンテンツ技術

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

解説

映像しか含まないコンテンツは、全盲の利用者及びロービジョンの利用者にとってはアクセシブルではない。そのため、これらの利用者が音声による代替コンテンツを利用できることが重要である。その一つの方法として、映像に含まれている情報を説明する音声トラックを提供する方法がある。この音声は、例えばMP3のように、インターネット上で一般的に使われている音声フォーマットである必要がある。

事例

事例 1

ウェブページに、宇宙船の火星着陸シーンの映像しか含まないプレゼンテーションへのリンクがある。そして、この映像へのリンクは、宇宙船の写真である。この映像を説明する音声ファイルへのリンクが、映像の近くにある。これは、次のHTMLコード例のようになるだろう。

コード例:


<a href="../video/marslanding.mp4"><img src="../images/spaceship.jpg" 
   alt="火星着陸(映像のみ)" width="193" height="255"/></a>
<br />
<a href="Mars_landing_audio.mp3">映像「火星着陸」の音声解説</a>

検証

チェックポイント

映像しか含まないウェブページに対して:

  1. 映像しか含まないコンテンツの直前又は直後に、映像のコンテンツを説明する代替の音声コンテンツへのリンクがある。

判定基準
  • 1. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G167: 隣接するボタンを用いて、テキスト・フィールドの目的をラベル付けする

適用(対象)

フォームをサポートするウェブコンテンツ技術すべて

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

解説

テキストフィールド上である機能を実行するボタンがあり、ボタンは明確にラベル付けされていて、テキストフィールドと隣り合って表示される場合、ボタンはテキストフィールドに対するラベルとしての役割も果たす。このラベルは、ページ上に新たな反復的なテキストを追加することなく、利用者がこのテキストフィールドの目的を理解するのを助ける。一つのテキストフィールドをラベル付けするボタンは通常はテキストフィールドの後に置かれる。

注記: 達成基準4.1.2を満たすため、このボタンはプログラムで解釈可能な識別名(name)を持っていなければならない。

事例

事例 1: 検索機能

あるウェブページには、利用者が検索文字列を入力するためのテキストフィールドと、検索を実行するための「検索」とラベル付けされたボタンがある。ボタンはテキストフィールドの直後に配置されているため、このテキストフィールドが検索のための文字列を入力するためのものであることが利用者にとって明らかである。

画面イメージ:フィールドのラベルを提供するボタンが右側にあるテキストフィールド
事例 2: フォームの選択

あるフォームではアメリカ合衆国の利用者に記入を求めている。州によって法律や要求が異なるので、利用者は自分が居住する州に対応したバージョンのフォームを選択しなければならない。ドロップダウンリストから利用者が州を選択するようになっている。隣接するボタンには「この州のフォームを開く」とラベル付けされている。ボタンを押すと、選択した州のためのフォームを表示するウェブページに移動する。

検証

チェックポイント

この達成方法を用いているテキストフィールドとボタンに対して:

  1. テキストフィールドとボタンが、プログラムで解釈可能な読み上げ順序において、互いに隣接している。

  2. テキストフィールドとボタンが互いに隣接して表示されている。

判定基準
  • 上記のチェックポイント全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G168: 選択されたアクションを続行するために確認を求める

適用(対象)

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

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

解説

この達成方法の目的は、選択されたアクションが利用者の意図どおりであるかどうか、利用者に対して確認を求めることである。アクションが遂行された後では取消が不可能な場合は、この達成方法を用いる。これによって、利用者が誤ってフォームを送信してしまったり、データを削除してしまったりすることを防ぐことができる。

例えば、利用者が想定していた「送信」ボタンと「キャンセル」ボタンの提示順序が、システムの設定とは逆だった場合、ボタンを早く押し過ぎて予想とは違う順序であることに気付かないことによって、誤操作が起こりうる。利用者に確認の要求を提示することで、間違いに気付き、データの送信を中止する、又は入力したデータが失われないようにすることができる。

確認の要求では、選択されたアクション、及びアクションを継続した場合の結果を利用者に伝えるべきである。

事例

事例 1: 飛行機を利用した旅行

オンラインの旅行サイトで、利用者はいろいろな航空会社の座席の予約をして、旅程表を作成することができる。利用者はその時点での旅程表を確認して、修正したり、キャンセルしたりすることができる。旅行の予定をキャンセルしたいとき、ウェブページ上でその予約を見つけて、旅程表から削除する。このアクションで彼の座席の予約はキャンセルされ、元には戻らなくなる。利用者は選択したアクションによって現在の座席の予約がキャンセルされ、アクションが実行されると同じフライトでの予約が不可能になることを知らされる。利用者は予約を取り消してよいか、又は予約の取消を中止するかの確認を求められる。

事例 2: ウェブメール

ウェブメールのアプリケーションが、インターネットにつながっている場所ならどこからでもアクセスできるように利用者の電子メールをサーバー上に保存している。利用者が電子メールのメッセージを削除する場合、間違って削除してしまっても取り出すことができるゴミ箱フォルダーにメッセージは移動される。ゴミ箱フォルダのメッセージをサーバーから削除するための「ゴミ箱を空にする」コマンドがある。ゴミ箱フォルダーが空にされると、メッセージは2度と取り出すことはできなくなる。そのため、ゴミ箱フォルダーを空にする前に、利用者はゴミ箱フォルダの電子メールを削除してよいか、又は削除するのを中止するかの確認を求められる。

事例 3: オンライン上の試験

試験の答案の回収用にフォームが使用されている。「送信」ボタンまたは「リセット」ボタンが選択されると、ウェブページ上で、どちらを選択したかが表示され、続行してよいか確認を求められる。事例 1:「フォームをリセットするを選択しました。入力したデータは全て削除され、回答は送信されません。フォームをリセットしますか? [はい ボタン][いいえ ボタン]」。事例 2:「フォームを送信するを選択しました。入力されたデータはあなたの最終回答として送信され、変更することができなくなります。フォームを送信しますか?[はい ボタン][いいえ ボタン]」。

事例 4: 株取引

株取引のサイトで利用者は株や他の証券の売買ができる。取引時間内に利用者が取引を行った場合、取引は即時に処理され、変更不可能であるということがダイログで提示される。ダイアログには、「続ける」ボタンと「中止する」ボタンがある。

検証

チェックポイント
  1. 破棄又は変更が不可能なアクションを始める。

  2. 選択されたアクションに対して、確認の要求が提示される。

  3. アクションを確定することができる、及びアクションを取り消すことができる。

判定基準
  • 2.及び 3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G169: テキストを左寄せ又は右寄せにする

適用(対象)

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

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

解説

認知障害のある利用者の多くは、均等割り付けの(左と右マージンの両方に位置合わせされた)テキストのブロックに大変に苦労する。単語の間の空白は、ページの下のほうへ流れている「余白(隙間)の川」を作り、一部の人々にとってテキストを読むことが困難になる。この問題を避ける最も良い方法は、テキストを均等割り付けにしないことである。

事例

事例 1

ほとんどのウェブコンテンツ技術において、すべての位置決めの宣言を単純に省く。例えば、以下のテキストは、ページの言語が左から右に流れるHTMLにおいて、初期設定として左に揃えられる。

コード例:


<p>
Lorem ipsum dolor sit amet, ...
</p>
事例 2

ウェブページは配置指定が混在した区域を含んでいる。ページの本文の段落は左のマージンに揃えられている。また、テキストには、多くのプル・クオート【訳注:(大きめの文字で表示された記事からの引用または手を入れた抜粋)】があり、それらは右のマージンに揃えられている。

検証

チェックポイント
  1. 一般的なブラウザでページを開く。

  2. コンテンツが均等割り付け(左と右マージンの両方に揃える)になっていない。

判定基準
  • 2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G170: 自動的に再生される音声を停止するコントロールを、ウェブページの先頭付近で提供する

適用(対象)

自動的に再生される音を含むウェブコンテンツ技術全て

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

解説

この達成方法の目的は、ページが読みこまれたときに自動的に開始する音声を、利用者が停止できるようにすることである。利用者が容易に素早く見つけることができるように、音声を停止するコントロールはページの先頭付近に配置しなければならない。これは、支援技術(スクリーンリーダー、画面拡大ツール、入力装置(スイッチ)など)を利用する人々及びそうでない人々(認知、学習及び言語障害のある人々)の役に立つ。

この達成方法では、コンテンツ制作者は、自動的に再生されたあらゆる音声を利用者が停止できるコントロールを組み込む。コントロールは、キーボードで操作が可能で、タブと読み込みの順序が早くなるよう配置され、再生されている音声を停止することを示すよう明確にラベルづけされていなければならない。

事例

事例 1

ウェブページは、草刈り機のエンジンを修理する方法を示す動画と音声トラックを含む、時間の経過に伴って変化するメディア・プレゼンテーションがある。ページは「一時停止」と「停止」というふたつのボタンを含んでおり、時間の経過に伴って変化するメディアが再生されるとき、これらは利用者にコントロールを提供する。

事例 2

ウェブページには短編映画が埋め込まれている。ページには「映画を一時停止する」というボタンがあり、利用者が映画を一時停止させることができる。

事例 3

ウェブページには動画と音声を含むFlashプレゼンテーションがある。ページには「マルチメディアを停止する」というボタンがあり、再生されているあらゆる動画と音声を利用者が停止できる。

検証

チェックポイント
  1. ウェブページをロードする。

  2. 自動的に開始する音楽や音声を確認する。

  3. 利用者が音声を停止することができるコントロールが、ページの先頭付近で提供されている。

判定基準
  • 3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G171: 利用者の要求に応じてのみ、音声を再生する

適用(対象)

音を再生できるウェブコンテンツ技術すべて

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

解説

この達成方法の目的は、ウェブコンテンツにおける音声の使用を利用者が制御できるようにすることである。スクリーンリーダーを使う利用者にとっては、ウェブコンテンツから音声が再生されていると、スクリーンリーダーの音声を聞き取る上で非常に気が散ったり聞き取るのが困難になるかもしれない。利用者の要求によってのみ音声を再生する方法を提供することで、利用者はスクリーンリーダーからの出力と干渉せずに音声を聴くために必要な制御を行えるようになる。

事例

事例 1

あるコククジラ保護団体のウェブページでは、コククジラの鳴き声と水しぶきの音が背景として繰り返し流れるようになっている。その音声は自動的には開始されない。その代わり、ウェブコンテンツには先頭付近に、利用者が手動で再生を開始できるボタンが置かれている。ボタンには「音声を再生」と書かれており、このボタンを押すことで音声が聞こえてくる。再生が始まると利用者には「音声を停止する」という選択肢が提供される。

事例 2

コククジラの音が含まれる音声ファイルへのリンクが提供されている。リンクテキストには「コククジラの鳴き声を聴く(MP3)」と書かれている。

検証

チェックポイント
  1. 3秒間以上の音声を再生するウェブページを読み込む。

  2. 音声が自動的に再生されない。

  3. 利用者が手動で音声の再生を開始する方法が提供されている

判定基準
  • 3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G172: テキストの両端揃えを解除するメカニズムを提供する

適用(対象)

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

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

解説

この達成方法の目的は、両端揃えをしていないバージョンのページを提供することである。

コンテンツ制作者は、レイアウトの目的でテキストを両端揃えにしたいと思う場合があるかもしれない。この場合、テキストの両端揃えを解除する機能を提供すればよい。そのためのコントロールは、探し出しやすく、アクセスしやすいように、ページの先頭の近くにおくとよい。

注記: この達成方法は、適合していないコンテンツに対して適合している代替版のページを提示するために、スタイルを切り替える達成方法と組み合わせて用いられる。詳細は、C29: 適合している代替版を提供するために、スタイル・スイッチャーを使用する (CSS) 及び適合している代替版を理解するを参照。

事例

事例 1

両端揃えで、元々出版された作業の外観の再現を試みたオンラインの古典小説がサイトにある。「両端揃えを解除する」と書かれたボタンがページの先頭近くにあり、スタイルシートを切り替えるためにスタイルを切り換える達成方法が使用されている。新しいスタイルシートでは、テキストを左揃えで配置する。

検証

チェックポイント
  1. 両端揃えのページを開く。

  2. 両端揃えを解除する機能がある。

  3. その機能により、両端揃えが解除できる。

判定基準
  • 2.及び3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G173: 映像の音声解説付きバージョンを提供する

適用(対象)

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

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

解説

この達成方法の目的は、映像コンテンツに対して音声解説を提供する別のバージョンを用意することによって、目で見ることのできない利用者が視聴覚コンテンツを理解できるようにすることである。

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

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

ムービーに音声解説を一次的な音声トラックとして含んだ別のバージョンを提供することによって、発話内容を聞くだけでなく登場人物の発話内容からだけでは伝わらない文脈や映像の他の側面も聞く必要がある全盲の利用者にとって、このコンテンツをアクセシブルなものにすることができる。

事例

  • オペラの映像に 2 つのバージョンが提供されている。1 つめのバージョンには、音楽だけが入っていて、2 つめのバージョンには、音楽のほかに、舞台上の歌手の行動を説明する音声ガイドが入っている。

  • 子どもたちの前でパフォーマンスをするジャグラーの映像に、音声ガイドのあるバージョンが含まれている。音声ガイドのナレーションでは、ジャグラーが投げ上げている物の数や種類、そのパフォーマンスを見ている子どもたちの反応などが説明されている。

参考リソース

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

検証

チェックポイント
  1. 主音声のトラックからだけでは理解できない重要な視覚的な情報を含むメディアを開く。

  2. 映像の音声を聞く。

  3. 発話の合間を用いて、視覚的に伝えているコンテンツに関する重要な情報を伝えている。

  4. 代替版(音声解説付きのバージョン)が別のページにある場合、そのバージョンへのリンクが提供されている。

判定基準
  • 3. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G174: 十分なコントラスト比のあるコントロールを提供して、利用者が十分なコントラストのある表現に変換できるようにする

適用(対象)

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

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

解説

テキストとそのページの一部の背景の間のコントラストが達成基準1.4.3または1.4.6のコントラストレベルを満たすように作られていない場合、適合要件 1における「代替版」を用いる ことでこれらのガイドラインを満たすことが可能である。ページのリンク又はコントロールは、ページを変更することによって 全ての側面を適合させたり、閲覧者を求められるレベルに適合した新しいバージョンのページに導いたりすることができる。また、そのリンクまたはコントロールをウェブページ上の目立つところに置くことによって、利用者が適合しているコンテンツにアクセスしやすくなる。

この達成方法を正しく用いるためには、次の三つを満たさなければならない。

  1. オリジナルページにあるリンクやコントロール自身は、求められる達成基準のコントラスト要求を満たさなければならない(もし利用者がコントロールを見ることができない場合、新しいページに行くためにそれを使用することができないかもしれない)。

  2. 新しいページはオリジナルページと同様に全ての情報と機能性を含んでいなければならない。

  3. 新しいページは求められる適合レベルのための全ての達成基準に適合すべきである(つまり、新しいページは求められたコントラストレベルは確保しているが他は適合していないということであってはならない)。

この達成方法は、ページの代替版のテキスト(又はテキストの画像)に背景と4.5:1のコントラストがある、及び大きいサイズのテキスト(又は大きなテキストの画像)に背景と3:1のコントラストがあることによって達成基準1.4.3を満たすために用いることができる。もしページの代替版に7:1のコントラストのあるテキスト(テキストの画像)と4.5:1のコントラストのある大きいサイズのテキスト(又は大きなテキストの画像)があるならば、それは達成基準1.4.3と1.4.6の両方を満たしている。

注記: この達成方法は、非適合コンテンツのための適合している代替版である現在のページにスタイルを切り替える達成方法と組み合わせることで用いることができる。詳しくは、 C29: 適合している代替版を提供するために、スタイル・スイッチャーを使用する (CSS) と適合している代替版を理解するを参照。

事例

検証

チェックポイント
  1. オリジナルページ上に代替版へのアクセスを提供するリンクやコントロールがある。

  2. オリジナルページのリンクやコントロールが、該当する適合レベルの全ての達成基準に適合している。

  3. 代替版のページが、コントラスト及び該当する適合レベルの他の全ての達成基準を満たしている。

判定基準
  • 上記の全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G175: 背景及び前景の色を複数から選択できるツールをウェブページ上で提供する

適用(対象)

利用者が他のページで再利用するために設定を保持できる全てのウェブコンテンツ技術

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

解説

この達成方法の目的は、ウェブページ又はウェブページ一式にコントロールを組み込み、利用者がコンテンツに対して好みの前景色及び背景色を指定できるようにすることである。この達成方法は、利用者が複数のページにわたって利用可能な設定を保持可能なウェブコンテンツ技術であればどれを用いても実装することができる。コンテンツ制作者はこの達成方法を使用して、利用者がサイト内の他のページでも使用可能な好みの前景色及び背景色を選択し、保存できるカラーピッカーコントロールを組み込む。各ページはこの設定を探し、保存された設定を見つけたら適用するように設計する。

認知障害のある利用者の多くは、標準的な白い背景に黒いテキストがあるページを読むのに苦労している。テキストと背景に別の色を用いるとテキストが格段に読みやすくなる場合があるが、これらの色の組合せは個別性が高く、他人には想定しにくい(例えば青の背景色に茶色のテキスト)。

このような利用者は、ブラウザの色の設定機能、又はOSの色の設定機能を使って色を設定することが困難なことがある。ウェブページ上に前景及び背景の広範な色の指定ができるツールを提供して、ブラウザの設定の中まで進まなくても簡単に色を変更することができるようにする。

事例

事例 1

利用者がテキストフィールドに16進数の値を入力できる。又は、"Pick"(選択)のリンクで隣接したフィールドに対する色選択ツールを開く。

スクリーンショット:16進数の値が入力された複数のテキストフィールドで前景色と背景色を設定するカラーコントロールを表示している。それぞれのフィールドにはラベルとテキストフィールドの中間に配置されたカラーピッカーを開くリンクがある。

色を選択するために色選択ツールを開く。

スクリーンショット:カラーピッカーのある色選択ツールが前景色を選択するために開いており、利用者は216色の中から選べるようになっている。

PHP、Javascript、CSS及びXHTMLを使って実装した、この達成方法の実装例がある:カラーピッカーの例

参考リソース

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

検証

チェックポイント
  1. ページ上に色選択ツールとわかるコントロールがある。

  2. 色選択ツールでテキストと背景色のために様々な色の選択ができる。

  3. そのツールを使ってテキストと背景に新しい色を選択する。

  4. コンテンツが選択した色の組合せに更新される。

判定基準
  • 1.及び4.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G176: 閃光を放つエリアを十分に小さくする

適用(対象)

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

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

解説

この達成方法の目的は、閃光を放つが小さいものに関して、達成基準を満たす容易な方法を提供することである。

ある1秒間において3回以上の閃光を放つものがある(つまり、G19の達成方法を用いることができない)が、閃光を放つ領域が視野10度(これは視界における中心視野に相当する)の25%未満である場合、自動的に達成基準を満たすことになる。

視野10度は、視界における中心視野にあたる。この視野には、視覚センサーがたくさんある。この視野における閃光は、視覚野に送られる。光過敏性発作のある利用者は、視覚野上において閃光を受け取ることで発作を引き起こす恐れがある。その他の視野(視覚センサーがずっと少ない部分)での閃光は、視覚野に与える影響がずっと少ない。そのため、中心視野の10度だけを対象とする。

公式 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平方度に相当する領域である。

  1. 画面との距離を矩形サイズに変換するには、その画面との距離に0.1745 (10 * Pi / 180)を掛けて矩形の幅を算出し、画面との距離に0.1309 (7.5 * Pi / 180)を掛けて矩形の高さを算出する(この計算は、インチ、ミリメートル、又はその他のあらゆる長さの単位で用いることが可能)。

  2. 視野角10度のサイズをピクセルで定める。

    それには、単位長さあたりピクセルで、手順1で算出した矩形の幅及び高さに画面解像度を掛けて、矩形の水平方向及び垂直方向のサイズをピクセルで算出する。

    • 1080p(1920 x 1080 ピクセル)のワイドスクリーンのディスプレイの場合、ピクセル・パー・インチでの画面の解像度は、2203を対角線の画面サイズ(インチ)で割った数になる。

    • 720p(通常は、1365 x 768 ピクセル)のワイドスクリーンのディスプレイの場合、ピクセル・パー・インチでの画面の解像度は、1566を対角線の画面サイズ(インチ)で割った数になる。

    • ピクセルピッチをミリメートル又はピクセルで指定したLCDのコンピュータのモニタの場合、ピクセル・パー・インチでの画面の解像度は、25.4をピクセルピッチ(ミリメートル)で割った数になる。

    どんなディスプレイでも、実際の対角線の画面サイズがインチでわかっていて、ディスプレイの水平方向と垂直方向の解像度がピクセルでわかっている場合、ピクセル・パー・インチでの画面解像度は、 ( (水平方向の解像度:ピクセル) x (水平方向の解像度:ピクセル) + (垂直方向の解像度:ピクセル) x (垂直方向の解像度:ピクセル) )の平方根である。

  3. 矩形の幅に高さを掛けて、4で割る。

事例

  • コンテンツ制作者が、会社の入口ラウンジにあるスクリーンで流れるアニメーションを制作する。ディスプレイのサイズ及び画面解像度とディスプレイを見る際の最も近い画面との距離から、中央視野 10 度の 25 %をピクセルで計算している(前述の公式を使用)。これは小さくて安全な領域といえる。コンテンツ制作者は、その小さくて安全な領域よりも大きい領域で閃光を放つことがないように留意している。

参考リソース

検証

チェックポイント
  1. 小さくて安全な領域を計算する。

  2. どのタイミングにおいても画面の一つの領域だけが閃光を放っている。

  3. 閃光を放つコンテンツは、小さくて安全な領域よりも小さいコンテナ内に収まっている。

判定基準
  • 2.及び3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G177: テキストの修正候補を提示する

適用(対象)

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

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

解説

この達成方法の目的は、利用者が入力した情報が受け付けられないとき、正しいと思われるテキストを推測できる場合には、そのテキストを提示することである。修正候補としては、正しい綴りのテキストや、あらかじめ蓄積されているテキスト群にある類似したテキストなどが含まれる。

フォームによって修正候補の提示方法は異なるが、エラーが発生した入力欄の横、ページの他の部分に表示することもできるし、検索機能やリンクを用いて修正候補の一覧が掲載されている他のURIに誘導することもできる。可能であれば、修正候補は利用者にとって利用しやすい方法で提示すべきである。たとえば、誤った情報が送信されたとき、利用者が意図した内容をチェックボックスやラジオボタンを用いて選択できるような形式で修正候補の一覧を提示するような方法が考えられる。修正候補や修正候補へのリンクは、たとえば、フォームの先頭、エラーがあるフィールドの直前または直後など、エラーを含むしたフォーム・フィールドの近くに配置しなければならない。

事例

検証

チェックポイント
  1. フォーム・フィールドのうち、誤ったテキスト入力から正しいテキストを推測可能なものを抽出する。

  2. フォームに入力し、抽出したフィールドには意図的に誤ったテキストを入力する。

  3. 利用者に対して修正候補が提示される。

  4. 修正候補、もしくは修正候補へのリンクが、エラーを含むフィールドの近くに配置されている。

判定基準
  • 3. 及び 4.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G178: 利用者がウェブページ上のすべてのテキストを 200%まで徐々に変更できるコントロールをウェブページ上で提供する

適用(対象)

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

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

解説

この達成方法の目的は、文字のサイズを徐々に大きくするメカニズムをウェブサイト上で提供することである。多くのロービジョンの人々は拡大鏡ソフトウェアを使っておらず、そしてブラウザの文字サイズの調整について精通していない。このことは、あとからコンピューターを学んだり、また失明に近い症状の高齢者にも特に当てはまる。 これはフォントサイズを大きくしたいと思っている認知障害者もまた同様である。

この達成方法は、利用者がより簡単に使うことのできるメカニズムを提供する。このメカニズムは視覚的表現を異なるスタイルシートに切り替えたり、文字サイズをダイナミックに変化するためのスクリプトを使用したりするリンクやボタンを含んでいる。

この達成方法を実装するために、コンテンツ制作者は利用者がページ上のすべてのテキストの文字サイズをデフォルト文字サイズの少なくとも200%の大きさに徐々に拡大縮小することができるコントロールを提供する。

これはリンクやボタンまたはリンク画像によって達成可能であり、そしてそれらコントロールは可能な限り簡単に見つけられるべきである。(ページ内で目立つ場所にある、大きなテキスト、ハイコントラストで表現されているなど。)

この達成方法は、レガシーコードの場合のように、拡大縮小可能なフォントを用いることができない状況でも同様に用いることができる。

注記: この達成方法は、非適合コンテンツのための適合している代替版のページを表示させるためのスタイル切り替えの達成方法との組み合わせで用いることができる。更なる情報はC29: 適合している代替版を提供するために、スタイル・スイッチャーを使用する (CSS) と適合している代替版を理解するを参照。

事例

検証

チェックポイント
  1. ビューポートのサイズを 1024px × 768px 以上に設定する。

  2. 文字サイズを大きくできる。

  3. 文字サイズが元のサイズから200%まで大きくすることができる。

  4. 文字サイズが元のサイズから200%まで大きくした後、コンテンツまたは機能が損なわれていない(例えば、テキストの一部が表示されなくなる、ボックスが重なり合う、コントロールが隠れてしまったりラベルから離れてしまったりする、というような状態にならない)。

  5. 文字サイズを初期値まで小さく戻すことができる。

判定基準
  • 2. ~ 5. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G179: 文字サイズを変更しても、テキストコンテナの幅が変更されない際に、コンテンツ又は機能が損なわれないようにする

適用(対象)

ウィンドウのサイズを変更するとテキストを折り返す、全てのウェブコンテンツ技術

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

解説

ユーザエージェントの中には、テキストコンテナの幅又は高さを変えることなく、文字サイズの変更をサポートしているものがある。コンテンツ又は機能の損失は、テキストがその割り当てられたスペースからあふれてしまう時に起こりうる。しかし、レイアウトのプロパティは、コンテンツの表示を効果的に継続する方法を提供することができる。 ブロックのサイズは、200%まで変更した時に文字があふれないほどの十分な幅を定義している。 文字はブロック内に入りきらない時包まり、そしてブロックは、ブロック内にすべての文字が入り続けるために十分な高さとなる。ブロックは変更された文字が入りきらない時、スクロールバーを提供する。

事例

事例 1: マルチコラムページレイアウト

HTML と CSS はテキストのページのために2つのカラムのレイアウトを作るために使われている。white-space 特性とnormalのデフォルト値を使うことで文字を包み込んでいる。文字のサイズが 200 %になると、文字は再びあふれ、テキストのカラムは長くなる。もしカラムが表示域に対して長すぎると、コンテンツ制作者が overflow:scroll 又は overflow:auto の CSS ルールを指定しているため、ユーザエージェントはスクロールバーを提供し、利用者がビューの中にテキストをスクロールすることができるようにする。

事例 2

カラムの中でテキストブロックでレイアウトしている新聞がある。そのブロックは横幅は固定されているが、高さは指定していない。ブラウザでテキストが変更された時、文字は包まれ、ブロックは高さが高くなる。

事例 3: 関係するテキストとコンテナにパーセンテージとem単位を用いてサイズを指定する

テキストとコンテナの両方に関係する単位を使うことは、テキストに切り捨てすることなく適応させるようにコンテナを拡張することができる。 この画像はインターネットエクスプローラーにおける”標準”サイズの文字である。灰色のボックスはdivのコンテナである。

スクリーンショット:標準の文字サイズ

この画像はInternet Explorerの“最大”の文字サイズを用いて同じテキストとコンテナを示している。灰色のボックスはより大きなテキストを囲むために拡張している。

スクリーンショット:最大の文字サイズ

コード例:

<style type="text/css">
  div { background-color:#ccc; line-height:120%; position:relative; }
  div.RelativeRelative { font-size:100%; width:8.1em; height:6.7em; }
</style>

<div class="RelativeRelative">
  すべての善良な人々にとって彼らの国を援助するのは今だ。
</div>

検証

チェックポイント
  1. 文字サイズが200%に拡大する。

  2. すべてのコンテンツと機能が閲覧及び使用可能である。

判定基準
  • 2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G180: 利用者が初期設定の制限時間を 10 倍に設定できる手段を提供する

適用(対象)

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

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

解説

この達成方法の目的は、障害のない利用者に比べて障害のある利用者が長時間必要とするかもしれないタスクにおいて、障害のある利用者に完了するための十分な時間を提供することである。環境設定又はページ上のコントロールのようなメカニズムによって、利用者がデフォルトの制限時間の少なくとも10倍まで制限時間を延長できるようにする。可能であれば、このメカニズムはさまざまな調整機能を備え、利用者が制限時間を範囲内の任意の値に変えられるだけでなく、任意の増減幅で変えられる方法も提供するとよい。これにより、利用者は、制限時間のあるセッションを始める前に、制限時間を変更できるようになる。

事例

検証

チェックポイント
  1. 制限時間をデフォルトの10倍に設定できるメカニズムがある。

  2. 制限時間をデフォルトの10倍にあたる新しい値に変更する。

  3. 制限時間のあるタスクを遂行する。

  4. デフォルトの制限時間が経過するのを待つ。

  5. 上記 2. で設定した制限時間になるまで時間切れにならない。

判定基準
  • 1. 及び 5. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

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

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

解説

利用者に認証を求めるウェブサーバは、一定時間、利用者の操作がない場合、セッションを終了することがよくある。利用者が素早くデータを入力できず、送信前にセッションが時間切れになってしまった場合、プロセスの続行前にサーバから再認証が求められるだろう。この場合、サーバはフォームからの情報(隠しデータ)を再認証ページに受け渡す。その後、利用者が再認証したら、フォームデータを直接送信するか、確認データを含んだページを表示するために、サーバは再認証ページから受け渡された情報を利用する。この達成方法では、サーバは利用者が送信したデータを保存しておかなくてもよい。この達成方法が重要なのは、サーバに一時的に情報を保存することが、違法性やセキュリティリスクに関わるケースである。また、サーバが記録した情報を保持しつづけたり、新しく認証したセッションでその情報に再接続する必要性から解放する点でも有用である。

注記: 利用者から送信されたデータが機密情報であったり、セキュリティリスクの疑いがある場合、データを再認証ページに受け渡したり、再認証後、データ保護を保証するために元のデータを処理してページに受け渡すプロセスを、コンテンツ制作者は見直すべきである。

事例

検証

チェックポイント

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

  1. ログインし、時間制限のある操作を始める。

  2. セッションを時間切れにさせる。

  3. データを送信する。

  4. 再認証する。

  5. 再認証後に元のデータや変更内容が保持された状態で、その後のプロセスが継続可能で、データの欠落なく完了できる。

  6. ステップ 3.で送信した情報を保存するために用いた途中経過のデータが、サーバに残っていないことを確認する(注記:この手法を実行するための技術や機能の知識が必要である)。

判定基準
  • 5. 及び 6. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G182: テキストの色の違いで情報を伝える際は、視覚的な手がかりを補足する

適用(対象)

次のように、色を用いて情報を伝えている際の色つきのテキスト:

  • パラグラフ内でリンクになっている語句

  • リスト内で、他のリスト項目とは異なり、色つきのテキストで提示されているリスト項目

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

解説

この達成方法の目的は、テキストの色の違いを識別することができない利用者に対して、同じ情報を示す豊富な視覚的な手がかりを提供することである。パラグラフの一部である語句又はテキストの他のブロックの一部である語句とは異なるステータスを示すために、又は特殊な文字あるいはグラフィックを用いて特別なステータスを有する語句を示すことができない場合に、色をよく用いる。例えば、テキスト内に散在している語句は、異なる色で表示されていれば、それがハイパテキストのリンクであることを示している可能性がある。この達成方法は、色の違いを知覚するのが困難な利用者又はロービジョンの利用者にその違いが分かるように、色に加えて手がかりを提供する方法に関するものである。

この達成方法を用いるにあたり、色だけを用いて情報を伝えている全ての箇所に対して、コンテンツ制作者は色に加えて視覚的な手がかりを提供する。視覚的な手がかりには、フォントのスタイル、下線の付加、太字、イタリックへの変化、又は文字サイズの変化などをはじめ、様々な形態が考えられる。

注記: 注記: この達成方法が達成基準 1.4.1 の視覚的な必須要件を満たしている時、色によって伝えられる情報は、達成基準 1.3.1 も満たすようプログラムで利用可能でなければならない。How to Meet 1.3.1を参照のこと。

事例

  • 同じページ上の他のテキストと異なる色で表示し、また色が識別できなくともリンクを識別できるよう下線とともに表示するのが、リンクの標準的なフォーマットである。

  • 様々なマークアップ言語における似た要素の使用法を比較した記事で、色つきのテキストを用いて各言語の要素を示している。1つめのマークアップ言語の要素には青色の太字のテキストを用い、2つめのマークアップ言語の要素には、赤色のイタリックのテキストを用いている。

  • あるニュースサイトでは、そのサイトに掲載されている記事の見出しを一覧にしている。例えば、その記事が掲載されているセクション、その記事が掲載された時刻、関連する場所、又はライブの映像があることを示す表示などの補足的な情報がある場合もある。そのような補足的な情報は、その記事へのリンクとは異なる色で提示されているが、利用者がリンクをより容易に見つけられるように、各リンクはその他のテキストよりも大きなフォントで提示されている。

  • 短めのニュース項目には、より詳細な情報へのリンクでもある文を含んでいることがある。パラグラフの残り部分では黒色のTimes-Romanという書体を用いているが、それらの文には色がついていて、サンセリフの書体を用いている。

検証

チェックポイント
  1. テキストの色を用いて情報を伝えている箇所を探す。

  2. 色を用いて情報を伝えているテキストは、スタイルも変えているか、又はその周囲にあるその他のテキストと視覚的に区別がつくフォントを用いている。

判定基準
  • 2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G183: 色の違いだけで示されているリンク又はコントロールは、その文字色と周囲にあるテキストとのコントラスト比を 3:1 以上にして、フォーカスを受け取ったときには視覚的な手がかりを補足して強調する

適用(対象)

段落中にあるリンクの文字列のように、情報を伝達するために色だけが使われているテキスト

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

解説

この達成方法の目的は、テキストの色の違いを識別することができない利用者に対して、同じ情報を示す豊富な視覚的な手がかりを提供することである。色は、段落や他のテキストのブロックの中にある文字列がリンクであることを示すために、一般的に使用されている。例えば、テキスト中に散らばる文字列が、周囲のテキストとの色の違いだけでハイパーテキストのリンクであると認識される。この達成方法は、色の違いを知覚することが困難である、又はロービジョンである利用者がそれらを見分けることができるよう、カーソルを重ねたりフォーカスが当たったときに、手がかりを補足する方法を説明している。

利用者がカーソルを合わせるかタブキーでリンクに移動するとき、この達成方法とともに視覚的な補足の確認手段があれば、テキストとその周りの相対輝度(明るさ)の差を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のコントラストを提供する色
事例 2

ドキュメントのハイパーテキストのリンクは中位の明るい青(#3366CC)で、通常のテキストは黒(#000000)である。なぜなら青のテキストは十分に明るく、周囲のテキストと3.9:1のコントラストを持ち、まったく色を見ることができない人も含め、すべての種類の色覚障害を持つ人々が周囲のテキストと違うことを識別することができるからである。

参考リソース

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

検証

チェックポイント
  1. テキストにおいて、情報を伝えるために色だけが使われているすべての箇所を見つける。

  2. テキストの色の相対輝度が、周囲のテキストの相対輝度と少なくとも3:1のコントラスト比の違いがある。

  3. リンクにカーソルを合わせる(マウスオーバーする)と視覚的に強調(アンダーラインやフォントの変更など)される。

  4. キーボード・フォーカスをリンクに合わせると視覚的に強調(アンダーラインやフォントの変更など)される。

判定基準
  • 2.、3.、及び4.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G184: フォーム又はテキスト・フィールド一式の先頭に、必要とされる入力フォーマットを説明するテキストの説明文を提供するt

適用(対象)

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

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

解説

この達成方法の目的は、利用者が入力しなければならないデータのフォーマットに関する制限を事前に知らせることによって、利用者が入力エラーを回避するのを助けることである。そのような制限に関する情報を一連のフォームの先頭で提示する。この方法は、少数のフィールドからなるフォーム、又は複数のフィールドが同じフォーマットのデータを要求するようなフォームにおいて最も有効である。このようなケースでは、フォーマットの説明をフォームの先頭に置く説明文で一度だけ提示するほうが、同じ説明を同一のフォーマット制限が要求されるフィールドすべてについて繰り返すよりも効果的である。

事例

事例 1

あるビジネスネットワーキングのサイトでは、利用者が自分の職歴に関する説明を投稿することができる。情報を入力するフォームには、企業名、役職、業務開始及び終了年月日、そして業務の説明などのフィールドがある。フォームの先頭には以下のような指示がある:

  • 「あなたのプロフィールに追加したい職歴について、必要事項を入力してください。 日付はyyyy/mm/ddの形式(例: 2009/01/01)で入力してください。」

事例 2

ある企業内アドレス帳では、利用者が自分のプロフィールを編集して、電話番号や職務内容をカスタマイズできるようになっている。フォームの先頭には以下のような指示がある:

  • 入力欄に表示された任意の情報を変更することができます。「終了」を選択すると情報が記録され、プロフィールを公開することができます。変更を破棄したい場合は「中断」を選択してください。

  • プロフィール中で、入力欄外にシステムのテキストとして表示された情報は変更できません。これらの情報は企業内人事情報から取得しています。編集できない部分に誤りや更新すべき情報がある場合は、表示情報の隣にあるヘルプアイコンを選択すると修正方法を確認できます。

  • 電話番号は半角の数字とハイフン(-)のみ入力できます。

  • 必須の入力欄はアスタリスク(*)で示されており、入力しなければフォームを完了できません。

検証

チェックポイント
  1. 利用者の入力データを所定のフォーマットでのみ受け付けるフォーム・コントロールを特定する

  2. フォームの先頭に、1.で特定したフォーム・コントロールすべての所定のフォーマットに関する説明文がある。

判定基準
  • 2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G185: HOME ページからサイト上の全てのウェブページにリンクする

適用(対象)

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

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

解説

この達成方法の目的は、利用者が小規模なウェブサイト内の全ての情報を探し出すことが可能となるように、HOMEページから全てのウェブページへのリンクを提供することである。サイトのページ数が十分に少ない時、HOMEページにおいて直接サイトマップの情報を提供することができる。ウェブサイト内のHOMEページ以外のページは、HOMEページへのリンクを提供する。

このように、HOMEページに一つで二つのメカニズムを持たせることができる。一つは各ページへの通常のナビゲーションを提供することであり、もう一つはサイトの事実上のサイトマップにもなることである。

サイト内の全てのウェブページは、全ての他のページへのリンクを提供し、一連のそれらのリンクは達成基準 3.2.3 (一貫したナビゲーション)を満たしている。

事例

検証

チェックポイント
  1. HOMEページは、ウェブサイト内の全ての他のページへのリンクを提供している。

  2. ウェブサイト内の他のページは、HOMEページへのリンクを提供している。

判定基準
  • 上記全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G186: 動きのあるコンテンツ、点滅するコンテンツ、又は自動更新されるコンテンツを停止させるコントロールを使用する

適用(対象)

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

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

解説

この達成方法の目的は、動きのあるコンテンツや点滅するコンテンツを、利用者が停止できるコントロールを提供することである。このようなコントロールがウェブページ上にあれば、そのコントロール自体は適切なレベルでのWCAGの適合要件、たとえば適切なコントラストであること、特定できる名前を持つこと、キーボードによるアクセスが可能であることに合致する。コントロールはページの先頭か、動きのあるコンテンツの近くに配置する。動きのあるコンテンツ又は点滅するコンテンツのすべてを1つのコントロールで停止できるか、コンテンツの別々の部分を別々のコントロールで停止できればよい。

事例

事例 1: 株式市場のティッカーテープ

あるウェブページに、株式市場の最新結果を表示する「ティッカーテープ」があり、画面の下に向かって自動スクロールする。利用者は「一時停止」ボタンでティッカーテープの動きを停止させることができる。一時停止を解除すれば、現在の株式市場の情報表示を再開する。

事例 2: 電子会議ツール

電子会議用のウェブページに、発言待ちのスピーカーの一覧がある。利用者は、新しい人が加わったり外れたりするときに一覧を自動更新するか、それとも「更新」ボタンを押したときにだけ更新するかを、ページ上のチェックボックスで選択できる。一覧が自動更新に設定されている場合、更新ボタンは非活性になっている。

検証

チェックポイント
  1. コンテンツの動き、点滅、自動更新を停止させるコントロールがウェブページ上にある。

  2. そのコントロールを有効にする。

  3. コンテンツの動き、点滅、自動更新が停止する。

判定基準
  • 1.及び3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G187: ユーザエージェントによって点滅するコンテンツを停止できるウェブコンテンツ技術を使用する

適用(対象)

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

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

解説

この達成方法の目的は、点滅するコンテンツをユーザエージェントの機能を使用して止めることができるようにすることである。特定のウェブコンテンツ技術では、ユーザエージェントによって利用者がアニメーションを止めることができる。利用者がこの機能を実行するとき、点滅も含めたすべてのアニメーションは停止する。この機能は、WCAGに適合したインタラクティブなコントロール、又は明記されたキーボード・ショートカットのいずれかによって提供することが可能である。

利用者がアニメーションを止めるための一般的な方法は、Escapeキーを押すことである。そのキーを押すためのイベントキューの中で先行するプロセスがない限り、動きのあるアニメーションや点滅しているコンテンツを停止するコマンドとして動作する。

一般的にこれが機能するとされているウェブコンテンツ技術:

  • Graphics Interchange Format(GIF)

  • Animated Portable Network Graphics(APNG)

事例

検証

チェックポイント
  1. 点滅するコンテンツを含むページを読み込む。

  2. ブラウザのアニメーションを止めるコマンドを実行する。(通常は、Escapeキー)

  3. 点滅が止まっている。

判定基準
  • 3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G188: 行送りや段落の間隔を広げるボタンをウェブページ上に提供する

適用(対象)

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

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

解説

多くの認知障害を持つ人々は行間がシングル・スペースに設定されたテキストを読む事が困難である。行の高さを増やすボタンは彼らが内容を読む助けとなる。段落の間が離れている状態を維持するためには、段落間の幅は、行送り幅の少なくとも1.5倍の高さになるように広げられるべきである。

注記: この達成方法は、非適合コンテンツに対して、適合している代替版のページを提供するための、スタイルスイッチの達成方法と組み合わせて用いることができる。詳細は、C29: 適合している代替版を提供するために、スタイル・スイッチャーを使用する (CSS) 、及び適合している代替版を理解するを参照のこと。

事例

事例 1

ページを変更するための標準的なスタイル・スイッチングを用いる。スタイルシートを切り替えるためのボタン又はリンクをページに用意する。新しいスタイルシートには、行送りを広げるルールと段落の間隔を広げるクラスが含まれている。

コード例:


        p {line-height: 150%; margin-bottom: 2em;}
      

参考リソース

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

検証

チェックポイント
  1. ページ内に行送りや段落の間隔を広げるためのボタン又はリンクがあり、そのことがわかるようにラベルづけされている。

  2. そのボタン又はリンクを起動する。

  3. ボタン又はリンクによって、行間が少なくとも1.5(150%)に広がる。

  4. ボタン又はリンクによって、各段落の間隔が行送りの少なくとも1.5倍より広くなる。

判定基準
  • 1.、3. 及び 4.を満たしている

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G189: ウェブページの先頭近くに、リンクのラベルを変更するコントロールを提供する

適用(対象)

リンクを実装できる全てのウェブコンテンツ技術

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

解説

この達成方法の目的は、ウェブページの先頭近くに、そのウェブページの適合している代替版へ利用者を誘導するコントロールを提供することである。その代替版では、各リンクのリンクテキストだけで前後の文脈を見なくてもリンクの目的がわかるようになっている。

利用者の中には、リンクの文脈を見なくても、リンクの目的がわかるのでリンクテキストにその文脈も含んだリンクを好む利用者がいる。一方で、文脈の情報を各リンクに含めることでリンクテキストが冗長になるため、サイトの使い勝手が悪くなると感じる利用者もいる。WCAGワーキンググループに支援技術の利用者から寄せられたフィードバックでも、どちらを好むかは意見が分かれている。この達成方法を用いることにより、利用者は、自分にとって最適なアプローチを選べるようになる。長くなる可能性があっても完全なリンクテキストを必要とする又はそれを好む利用者は、代替版を使用することができる。

代替版に変換するコントロールがリンクである場合、そのコントロールの目的が、常にリンクテキストだけでわかるようにしておかなければならない。

この達成方法は、現在のページ表示に対する代替版を提供する。この環境設定をクッキー又はサーバーサイドのユーザプロフィールに保存して、利用者が一度選択すれば、その後はサイトを訪れるごとに選択しなくても、自動的に利用者の好むバージョンが表示されるようにすることもでき、そうするのが望ましい場合もある。

注記: この達成方法は、表示スタイルを変更して非適合コンテンツに対する適合した代替版となるページを提供する達成方法と併せて使うことができる。詳しくは、C29: 適合している代替版を提供するために、スタイル・スイッチャーを使用する (CSS) 及び適合している代替版を参照のこと。

事例

事例 1: 別バージョンへのリンクを提供する

ウェブページに、様々なフォーマットでダウンロードできる書籍のリストがある。このウェブページの代替版では、書籍のフォーマットだけ、又は書籍名とフォーマットのタイプが、リンクテキストとして使われている。

短いリンクテキストのバージョン:

コード例:


...
<h1>書籍のダウンロード</h1>
  <p><a href="books-full-links.html" >完全なリンクのバージョン</a></p>

  <ul>
  <li>ウェブの歴史: 
  <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>書籍のダウンロード</h1>
  <p><a href="books-short-links.html" >短いリンクのバージョン</a></p>

  <ul>
  <li>ウェブの歴史:
  <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>

検証

チェックポイント
  1. ウェブページの先頭近くに、リンクテキストを変換するコントロールがある。

  2. コントロールを起動する。

  3. 変換されたウェブページでは、全てのリンクのリンクテキストがその目的を説明している。

判定基準
  • 1. 及び 3. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G190: 適合している代替版へのリンクを、適合していないオブジェクトの直前で提供する、又は適合していないオブジェクトと関連付ける

適用(対象)

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

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

解説

ページにあるすべてのオブジェクトが適合しているのがより望ましいが、それが可能ではない状況もある。オブジェクト又はコンテンツのセクションが特定の障害のある利用者を想定していると、一方でそういった同じ属性が他の利用者にとってアクセシブルではなくなるという状況がありえる。また、ウェブページ上に適合しているオブジェクトを持たない他の理由も考えられる。オブジェクトが適合していない際には、適合している代替版へのリンクが線形化した読み上げ順序の中で適合していないオブジェクトに隣接している、又は適合していないコンテンツと関連付けられている。適合している代替版は、適合していないバージョンと同じ情報を伝達している。

事例

事例 1: 音楽の芸術的な品位を阻害する音声解説のあるラップ音楽映像

「ヒップホップキッド」という名前のラップ音楽の映像には背景音がある。音声解説を歌の合い間に挿入することは、アーティストが伝えようとしているギターとドラムの最高潮の演奏を妨げるであろう。そのウェブページ上では、映像オブジェクトのすぐ次に「"ヒップホップキッド"の音声解説バージョン」というリンクがあり、映像の中で視覚的に何が起きているかという音声解説を含んでいるバージョンが提供されている。

事例 2: 歴史文書の画像

独立宣言についてのウェブページに、文書の画像がある。テキストと背景の間のコントラストは不十分であり、手書きの文書は読むことが困難である。利用者をその文書のHTMLバージョンへ誘導するリンクがある。

事例 3: アクセシビリティ・サポーテッドではないアニメーション

アクセシビリティ・サポーテッドではないウェブコンテンツ技術を使用して制作されたインタラクティブなアニメーションがウェブページ上で表示されている。アニメーションの適合している代替版へのリンクは、適合していないコンテンツに隣接している。

検証

チェックポイント

ページ内の適合していないオブジェクトそれぞれに対して:

  1. ウェブページ上に適合していないオブジェクトがある。

  2. 線形化した読み上げ順序の中で適合していないオブジェクトの直後に、オブジェクトの適合しているバージョンへのリンクがある。

  3. そのリンク先に適合しているバージョンがある。

判定基準
  • 2.及び3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G191: 点滅するコンテンツのないページを読み込むリンク、ボタン、又はその他のメカニズムを提供する

適用(対象)

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

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

解説

この達成方法の目的は、ウェブページに点滅するコンテンツがあると閲覧できない利用者が点滅をオフにできるようにすることである。適合要件 1では、代替ページを使用することによって適合要件を満たすことが認められている。この達成方法は、達成基準2.2.2に対してこのアプローチを取った例である。

点滅するコンテンツのないページが、点滅するコンテンツのあるページと全く同じ情報を提供していることが重要である。

注記 1: ウェブページから点滅するコンテンツを取り除くことは、そのコンテンツが点滅しないコンテンツと重複している場合にのみ有効である。

注記 2: この達成方法は、表示スタイルを変更して非適合コンテンツに対する適合している代替版となるページを提供する達成方法と併せて用いることができる。詳しくは、C29: 適合している代替版を提供するために、スタイル・スイッチャーを使用する (CSS) 及び適合している代替版を理解するを参照のこと。

事例

検証

チェックポイント
  1. 点滅のないウェブページを読み込むメカニズムがある。

  2. 再読み込みしたウェブページには点滅がない。

  3. 再読み込みしたウェブページでは、元のページにある情報及び機能が全て提供されている。

判定基準
  • 上記、全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G192: 仕様に完全に準拠する

適用(対象)

この達成方法は仕様のある全てのマークアップ言語に関連する

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

解説

マークアップ言語がその仕様に完全に準拠していれば、4.1.1のすべての要件が満たされる。つまり、仕様に完全に準拠することは、WCAG 2.0に適合するために必要ではないが、成功事例であり、達成基準4.1.1に適合することになる。

事例

検証

チェックポイント
  1. 全てのウェブコンテンツ技術が仕様に従って使用される。

注記: バリデータは、誤りを見つけるために素晴らしいツールであるが、通常、コンテンツが仕様に対して完全準拠となっていない事例のすべてを見つけられるものではない。

判定基準
  • 1.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G193: ウェブページでアシスタントによるヘルプを提供する

適用(対象)

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

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

解説

この達成方法の目的は、ウェブページを利用する際の支援となるマルチメディアのアバターを使ったヘルプを提供することである。アバターを使ったヘルプは、テキストを読むことが難しい認知障害のある利用者に特に役立つ。また、視覚情報を利用することで、提示された題材に集中するのに役立つことがある。

注記: マルチメディアのアバターはガイドライン 1.2の関連する達成基準も満たさなければならない。

事例

検証

チェックポイント
  1. ウェブページにアシスタント機能がある。

  2. アシスタントはそのページの内容の理解を手助けする情報を提供している。

判定基準
  • 上記の全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G194: スペルチェック機能を提供し、テキスト入力の修正候補を提示する

適用(対象)

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

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

解説

この達成方法では、スペルチェック機能やテキストの入力候補の提供について示している。認知障害のある利用者の場合、単語のおよその綴りは分かっても、正しく綴ることが難しいということがしばしばある。スペルチェック・プログラムを用いることで、単語の正しい綴りを調べるという時間のかかる作業を行わなくてもよくなる。これは、視覚障害のある利用者でミスタイプが多い場合にも有効である。また、手に障害があり、額に装着する形のポインティング・ディバイスを使用していたり、スキャン・ソフトウェアでオンスクリーン・キーボードを使用している、入力が困難で時間のかかる利用者にとっても有効である。入力単語の候補を提示し、簡単な仕組みで入力したい単語を選択することでテキストフィールドに入力できるような機能を持つスペルチェック機能は、こういった利用者にとって有効である。

事例

検証

チェックポイント
  1. ウェブページにテキストフィールドがある。

  2. 綴りが誤っている単語を入力する。

  3. 単語の修正候補が提示される。

  4. 提示された修正候補をフォームに入力するメカニズムがある。

判定基準
  • 3. 及び 4. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G195: コンテンツ制作者が提供する視認性に優れたフォーカスインジケータを使用する

適用(対象)

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

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

解説

この達成方法の目的は、視認性に優れたフォーカスを作ることによりブラウザのフォーカスインジケータを強調することである。多くのブラウザにおける初期値 のフォーカスインジケータは、細いドットの黒い線になっている。アウトラインを既に持っているようなフォーム要素を囲っている場合、テーブルセルの中にフォーカス要素が入っている場合、フォーカスされた要素がとても小さい場合、もしくはページの背景の色が濃い色の場合は、そのフォーカスを見ることが困難である。

この達成方法において、利用者がマウス、タブキー、矢印キー、キーボードのショートカット、もしくは他の方法を用いて要素にフォーカスを置いている時、アプリケーションは高いコントラスト比を持った色、太字、そして光を放つような視覚的インジケータを用いることによってフォーカスをより視認性のあるものにしている。

事例

事例 1: リンク

濃い背景色と明るい文字とリンクを持つウェブページがある。フォーカスがリンクにあたると、そのリンクは3ピクセルの明るい黄色のラインで囲まれる。

事例 2: フォーム要素

テーブルの中にフォームが書かれているウェブページがある。テーブルとフォームの要素の両方の境界は細くて黒い線になっている。フォーカスがフォーム要素に当たる時、その要素は部分的に透明になっている5ピクセルの赤い線で囲まれる。

事例 3: メニュー

サブメニューを持ったインタラクティブなメニューを含んだウェブページがある。利用者は矢印キーを使ってメニューの中でフォーカスを動かすことができる。フォーカスが動くと、フォーカスが当たっているメニュー項目はその背景を異なる色に変える。その色は周りの項目に対して3:1のコントラスト比を持ち、そのメニューのテキストの色と4.5:1のコントラスト比を持っている。

検証

チェックポイント
  1. マウスを用いてページ上のそれぞれのフォーカスできるユーザインタフェース要素にフォーカスを置く。

  2. 視認性に優れたフォーカスインジケータがある。

  3. キーボードを用いてページ上のそれぞれのフォーカスできるユーザインタフェース要素にフォーカスを置く。

  4. 視認性に優れたフォーカスインジケータがある。

判定基準
  • 2.及び 4.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G196: 画像のグループにある一つの画像に、そのグループのすべての画像を説明する代替テキストを提供する

適用(対象)

非テキストコンテンツのグループを用いて情報又は機能を提示する、全てのウェブコンテンツ技術

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

解説

この達成方法の目的は、隣り合う非テキストコンテンツのグループを用いて情報又は機能を提示する際に生じる不要な重複を回避することである。

ウェブページでは、画像のグループを提示して情報を伝えることがある。一緒に提示する、又は特定の組み合わせで提示することにより、こうしたグループは様々なタイプの情報を伝えることができる。例えば、2つの星の画像のうち1つを白黒、もう1つをカラーで表示し、利用者評価を表すために使用することができる。また、塗りつぶした3つの星に続いて塗りつぶしていない2つの星を提示すれば、利用者評価が満点の5つ星のうちの3つ星であることを示すこともできる。

この達成方法を用いるには、コンテンツ制作者が、グループ全体と等価の目的を果たす代替テキストをそのグループにあるどれか一つのアイテムに関連付けて提供する。そして、グループ内のその他のアイテムは、支援技術が無視できるようにする。こうすることによって、利用者は、より効率的にそのグループの目的を理解して、グループ内の各アイテムに代替テキストが提供した際に生じる重複又は混乱を回避することができる。

事例

事例 1: HTMLでの評価システム

次の例では、塗りつぶされた星3つと塗りつぶされていない星2つで評価が示されている。代替テキストは、5つの画像それぞれに提供することもできるが、このコンテンツ制作者は、1つ目の画像に「5つ星のうちの3つ星」として画像のグループが伝えている評価を提供し、他の画像には空の代替テキストを用いている。

コード例:


   <p>評価:
   <img src="star1" alt="5つ星のうちの3つ星">
   <img src="star1" alt="">
   <img src="star1" alt="">
   <img src="star2" alt="">
   <img src="star2" alt="">
  </p>
事例 2: XHTMLで画像のグループによって作成されたボタン

この例では、宣言しているWCAGへの適合レベルを示すために、各ボタンが複数の画像一式を用いている。このアプローチによって、支援技術は「画像A、画像A、画像A」などのように読み上げるのを回避できるようになる。

コード例:


 <p>適合レベル:</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>

検証

チェックポイント
  1. グループ内の一つのアイテムに、そのグループ全体の目的と等価な代替テキストがある。

  2. グループ内のその他のアイテムは、支援技術が無視できるようにマークされている。

  3. 支援技術が無視できるようにマークされたアイテムが、グループ全体に対する代替テキストのあるアイテムと隣り合っている。

判定基準
  • 上記全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G197: 同じ機能を有するコンテンツに対して、一貫したラベル、識別名及び代替テキストを使用する

適用(対象)

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

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

解説

この達成方法の目的は、認識障害、全盲もしくは弱視の利用者に対して、ウェブページ内の機能にインタラクトしたときに何が起こるかを理解するのを助けることである。同じ機能を提供する利用者・インターフェース・コンポーネント(要素、リンク、JavaScriptオブジェクトなど)に異なるラベルが付けられていると、利用者は同じ機能を持つコンポーネントに出会ったことに気づかず、何が起きるかを予測することができないだろう。これがたくさんの無用な操作ミスにつながるかもしれない。加えて、一貫したラベル付けに関するこのようなアプローチはウェブサイト全体に対して適用することを推奨する。

事例

検証

チェックポイント
  1. 各コンポーネントにはそれを特定できるテキスト(ラベル、識別名、代替テキストなど)が関連付けられている。

  2. このテキストは同じ機能を提供するコンポーネントに関しては同一である。

判定基準
  • 1.及び 2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G198: 利用者が制限時間を解除できる手段を提供する

適用(対象)

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

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

解説

この達成方法の目的は、指定された制限時間内にタスクを完了できない利用者に対して、制限時間を解除するメカニズムを提供することである。

制限時間を解除するメカニズム自体に制限時間が設けられておらず、またウェブページ全体の制限時間前に完了できるようにすることが非常に重要である。そのためには、さまざまな障害のある利用者がすばやく見つけて解除できるように、このメカニズムをページの上部又は上部近くで提供すべきである。

事例

検証

チェックポイント
  1. ウェブページの上部近くに、あらゆる制限時間を解除するメカニズムがある。

  2. ウェブページの制限時間は、一般的な利用者よりも10倍の時間を要する利用者でも、そのメカニズムを利用できるのに十分な長さである。

判定基準
  • 1. 及び 2. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G199: データが問題なく送信されたことを伝えるフィードバックを提供する

適用(対象)

利用者のデータインプットを受け入れているコンテンツ

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

解説

この達成方法の目的は、利用者にアクションを確認させる手間(例えば、ウェブフォームを送信した時に、それが正常に完遂されたことを利用者に確認させる)をなくすことである。アクションが成功したかを確認させるように促す代わりに、アクションが成功したか明確に示すフィードバックを常に提供することで達成することができる。

アクションを確認するために、情報に目を通すことが容易ではない利用者の大きな手間が費やされる時がある(例えば、データベースにデータが正常に送信されたか、人に送られたのか、または編集されているコンテンツに追加されたのか)。

事例

  • 利用者がシステムにログインする際、応答として「正常にログインできました」と表示される。そのため、利用者はログインできたかどうかを知るための手がかりとして、利用者名があるか、ログインリンクがログアウトリンクに変わったか、などを探して画面中を見てまわる必要がない。それらを探すことは、時間の浪費となる可能性がある。

  • 利用者がクイズやテストを送信する。応答において、テストが正常に送信されたと知らせている。そのため、利用者は送信が正常に行われたかを確認するために、送信されたテストのリストなどを探し回る必要がない。

  • 訪問者がウェブサイトでアカウントを作る。フォームを送信した後に、「登録が正常に送信されました……」とフィードバックされる。もし登録の後に自動的にログインするのであれば、フィードバックに「……ログインしました。」と追記される。もし確認が必要である場合、フィードバックは「……登録の確認を求めるEメールを送信しました」と続く。

  • 利用者がサポートスタッフに直接充てた情報をフォームで送信する。フィードバックは「メッセージは正常に送信されました。48時間以内に回答が届きます。」と示す。

検証

チェックポイント
  1. エラーがないようにフォームに入力する。

  2. フォームを送信する。

  3. 正常に送信できたことが、フィードバックメッセージとして表示されている。

判定基準
  • 3. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G200: 必要なときにだけリンク先を新しいウィンドウおよびタブで開く

適用(対象)

新しいウィンドウを開くウェブページ

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

解説

この達成方法の目的は、ウェブコンテンツ内で新しいウィンドウまたはタブを開くリンクまたはボタンの使用を限定することである。一般的に、新しいウィンドウやタブを開かないほうがよい。なぜなら、特に視覚的なコンテンツを知覚するのに困難を伴う利用者をはじめ、利用者にとっては混乱の原因となりうるからである。しかし、アクセシビリティの観点から、新しいウィンドウやタブを開くことが望ましい状況というのもある。例えば、次の二つのような場合である:

  1. 例えば、ヘルプの説明文またはカレンダーを用いたデート・ピッカー(日付選択)のようなフォーム入力の代替手段のように、状況に応じた情報を含むウェブページを開く際に、もしそういったウェブページが同じウィンドウやタブで開かれるとしたら、フォームを入力したり送信したりするような複数のステップから成るワークフローを著しく中断させることになる。

  2. 利用者がセキュアなサイトにログインしていて、そのサイト外にあるページへのリンクをたどっていくとログインした状態が打ち切られてしまう。この場合、外部へのリンクを別のウィンドウで開くことによって、利用者は元のウィンドウでログインした状態を保ちながら関連するリソースにアクセスすることができるようになる。

リンク先のウェブページが新しいウィンドウで開かれる際には、利用者に事前に知らせることが推奨される。

事例

事例 1: オンラインフォーム

各入力項目に対する状況に応じたヘルプをフォーム上で提供するには文字量が多すぎるため、別のウェブページで提供しているオンラインフォームがある。すでに入力済みのフォームデータが失われないように、状況に応じたヘルプへのリンクは新しいウィンドウまたはタブを開くようになっている。

事例 2: セキュアなウェブサイト

セキュアなウェブサイト内のあるウェブページにセキュアなセッション外にあるウェブページへのリンクがある。そのリンクを同じウィンドウで開くとセキュアなセッションが無効になってしまうため、新しいウィンドウまたはタブで開くようになっている。

事例 3: デート・ピッカー(日付選択)

オンラインフォームに日付のフィールドがあり、利用者は日付を入力するか、別ページのカレンダーを用いたデート・ピッカーから日付を選択することができるようになっている。すでに入力済みのフォームデータが失われないように、カレンダーを用いたデート・ピッカーへのリンクは新しいウィンドウまたはタブを開くようになっている。

参考リソース

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

Beware of opening links in a new window

Top-10 New Mistakes of Web Design


G201: 新しいウィンドウを開くときには利用者に事前に知らせる

適用(対象)

新しいウィンドウを開くウェブページ

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

解説

この達成方法の目的は、自動的に新しいウィンドウまたはタブを開く前に利用者に知らせることである。リンクを押下したときに自動的に新しいウィンドウを開くことは、もし事前にそのことを知らせていなければ、視覚的なコンテンツを知覚するのに困難を伴う利用者や認知障害のある利用者が混乱する原因となりうる。事前に知らせることによって、利用者は現在のウィンドウから離れるかどうかを判断することができるようになる。また、利用者が新しいウィンドウを開くことを選んだ場合にも、元のウィンドウに戻りやすくなる。さらに、ブラウザの[戻る]ボタンが使えないことや、直前まで自分がいた場所を見つけるためには元のウィンドウに戻らなければならないことを利用者が理解する手助けにもなる。

事例

事例 1: コントロールを説明するテキストで知らせる

コントロールを説明する識別名またはラベルを用いて、新しいウィンドウで開くことを知らせることができる。

コード例:


       <a href="knitting.html" target="_blank">編み物のすべて 
              (新しいウィンドウで開く)</a>
事例 2: CSSを用いて、新しいウィンドウが開く前に知らせる

以下のコードでは、CSSを用いて新しいウィンドウが開く前に知らせている。

コード例:


       <html>
                <head>
                <title>ポップアップによる警告</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>ポップアップによる警告</h1>
                <p> これは <a class="info" href="popup_advisory_technique.html"
                 target="_blank"><strong>外部へのリンク</strong>
                 <span>新しいウィンドウで開く</span></a>の事例です。
                </p>
                </body>
                </html>

検証

チェックポイント

利用者の要求による状況の変化が生じた際に新しいウィンドウまたはタブで開くリンクに対して:

  1. このリンクは新しいウィンドウを開くことが支援技術(音声ブラウザ/スクリーンリーダー)によって読み上げられる。

  2. このリンクは新しいウィンドウを開くことが視覚的に示されている。

判定基準
  • 1. および 2. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G202: すべての機能をキーボードだけでも操作可能にする

適用(対象)

インタフェース操作をサポートするウェブコンテンツ技術すべて

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

解説

この達成方法の目的は、ウェブページのすべての機能をキーボードで操作可能にすることである。ウェブコンテンツのすべての機能がキーボードまたはキーボード・インタフェースによって操作可能であれば、全盲の利用者や代替キーボード、音声入力ソフトウェアやオンスクリーン・キーボードのようなキーボード・エミュレータとよばれる入力デバイスを使用しなければならない利用者が操作できることになる。

たとえ使用している計算装置がハードウェアのキーボードを含んでいない場合も、キーボードインタフェースが利用者にキーの押下によるプログラムへのインプットを許容する。例えば、多くのモバイルデバイスはオペレーティングシステムにキーボードインタフェースか、又は外部接続のワイヤレスキーボードに接続する選択肢を持っている。アプリケーションは、外部接続のキーボードまたは他の模擬的にキーボードアウトプットができるサービスからキーボードインプットを得るインターフェースを使える。例えば、スイッチデバイス、手書き解釈プログラムまたは書き起こしアプリケーションなどがある。

この達成方法を用いるには、まずそのウェブページでどのような機能が利用者に提供されているのかを確認する必要がある。その際には、マウスやキーボードを使って使用する機能を特定することが重要である。そういった機能の例としては、リンク、メニュー、ボタン、チェックボックス、ラジオボタン、フォーム・フィールドのような操作系のものや、ドラッグ&ドロップ、テキスト選択、領域のサイズ変更、コンテキストメニューの表示のような機能的なものが挙げられる。他にも、ショッピングカートでのアイテムの追加や削除、販売担当者とのチャットの起動などのように、タスクをベースにした機能が例として挙げられる。

ウェブコンテンツが提供している機能を確認したら、コンテンツ制作者はそれぞれの機能がキーボードだけでも操作することが可能かどうかを検証する。

注記: 同じ機能を使用できる手段がウェブページ上で複数提供されている場合には、必ずしもそれぞれのコントロールをキーボードだけで操作可能にする必要はない。その場合、コンテンツ制作者には、利用者がキーボードで操作可能な手段を見つけやすくすることが推奨される。

事例

  • 利用者がマウスオーバーすると変化するリンク画像のあるウェブページがある。キーボード利用者に対して同様の体験を提供するために、利用者がキーボード操作でフォーカスをそのリンク画像に移動させたときにも画像が変化するようにしている。

  • リストにあるアイテムをクリックしてドラッグすると順序を入れ替えることができるウェブページで、キーボード操作でリスト内のアイテムの順序を前後に移動させたり、リストの先頭や最後に移動させたりすることのできるコントロール一式も提供している。

  • モバイル版ウェブサイトに、タップするとフロートオーバーレイでサイトメニューを開くメニューボタンがある。モバイルデバイスに接続する外部接続キーボードまたは特殊スイッチを利用している人々へのアクセスを提供するために、メニューボタン及びサイトメニューがいずれもモバイルデバイスのキーボードインタフェースで操作できるようにしている。

検証

チェックポイント
  1. ウェブコンテンツの機能すべてを特定する。

  2. キーボードのみ、またはキーボードインタフェースのみで全ての機能にアクセスが可能である。

判定基準
  • 2. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G203: 話者が話すのみの映像を説明するために、静的な代替テキストを使用する

適用(対象)

話者が話すのみの映像

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

解説

この達成方法の目的は、映像部分に含まれる、重要なタイムベースの情報がない同期されたメディアの音声についての解説に対する代替手段を提供することである。これは、特に、記者会見や社長の会見、政府の公式発表などの変化しない背景の前で話している人物の「語り手の顔」のビデオを指す。この場合、音声解説が保障するであろう「重要な視覚的詳細情報」はない。

一人の人物が変化しない背景の前で話している場合は、音声解説は必ずしも必要ない。なぜなら、この映像には、内容を理解するために「重要」な時間依存の視覚的情報がないためである。周囲の状況が変化しないため、映像にプログラム的に関連付けられた代替テキストのような、マルチメディアではない静的なフォーマットで記述できる。

この場合、静的なテキストによる代替を用意し、周囲の状況や文脈の説明、オープニング/クロージングクレジット、語り手の名前、その他基本的な情報など、画面に映りながら音声として聞くことができないものの一般的な解説をすれば足りる。

この達成方法は、複数の語り手がおり、音声ではそれぞれの新しい語り手が明確でないが、視覚的なテキストで明確にされているような状況では適用されない。その場合は音声解説を用いるべきであり、この達成方法は適用されない。

事例

事例 1: 事例1: 株主に語りかけているCEOの映像

CEOがオフィスで株主に語りかけている。この映像の冒頭には、日付の入ったタイトルカットがある。話が始まると、映像の下部に「XYZ社 社長 John Doe」とテキストが出てくる。映像の最後には「制作 Honest TV Productions Ltd.」とタイトルクレジットが出てくる。

代替として、映像の下にaria-describedby属性で映像ファイルと関連づけられた段落があり、「6月22日 John Doe XYZ社 社長 オフィスにて撮影。Honest TV Productions Ltd.制作」と書かれている。

検証

チェックポイント
  1. 映像トラックの中に時間依存の重要な情報がない。

  2. そのメディアにプログラムで関連付けられた解説が、音声に含まれていない内容の文脈を説明している(例えば、語り手の紹介、クレジット、文脈など)。

判定基準
  • すべてを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G204: 閲覧画面の幅を狭めたときに、ユーザエージェントによるテキストの折り返しを妨げない

適用(対象)

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

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

解説

この達成方法は、横スクロールが起こる状況を回避することを助けるものである。ブロックやテキストの横スクロールは、支援技術を用いていない認識障害がある人々やロービジョンの利用者にとっては大きな問題となる。ウィンドウ幅が狭い時にテキストのリフローを妨げないことも含まれる。最善の方法のひとつは、テキストブロックコンテナの横幅をパーセントで定義することである。

制作者が横幅をピクセルやポイントなどの絶対値で定義していない限り、ウィンドウ幅が狭い時、HTML及びXHTMLユーザエージェントは自動的にテキストをリフローする。

事例

事例 1

新聞社のサイトがユーザエージェントのウィンドウ幅に合わせたカラム数の記事を含んでいる。認知障害の利用者は、読みやすいようにカラムを狭めることができる。

参考リソース

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

検証

チェックポイント
  1. 一般的なユーザエージェントで、テキストブロックを含むコンテンツを開く。

  2. ユーザエージェントにリフローを許可する設定があるか確認し、あれば有効にする。

  3. ウィンドウ幅をスクリーン幅の1/4に縮める。

  4. 1行の文章を読むために、コンテンツを横スクロールする必要がない。

判定基準
  • 4. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G205: フォーム・コントロールの、色がついたラベルに対して、テキストによる手がかりを提供する

適用(対象)

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

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

解説

この達成方法の目的は、情報を伝えるために、色と、テキスト又は文字による手がかりを併用することである。ほとんどの利用者は色の差を用いた情報を素早く認識できる。色を識別できない利用者は、視覚的又は聴覚的にテキストによる手がかりを認識する。点字ディスプレイや、他の触覚インタフェースを使っている人々は触ることでテキストによる手がかりを見つけられる。

テキストによる手がかりは、フォームコントロールの、プログラムで解釈可能な名前の一部に含まれていなければならない。

事例

事例 1: HTMLフォームの必須項目

オンラインフォームで「必須項目は赤で示され、(必須)とマーク付けされている。」と指示されている。「(必須)」という手がかりがlabel要素の中に含まれる。

コード例:

<label for="lastname" class="required">名前 (必須): </label>
<input id="lastname" type="text" size="25" value=""/>
<style type="text/css">
  .required {
    color:red;
  }
</style>

参考リソース

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

検証

チェックポイント

色の差で情報を表示しているコンテンツの場合:

  1. 同じ情報がテキスト又は文字による手がかりでも認識できる。

判定基準
  • 1. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


G206: レイアウトを切り替えるオプションをコンテンツの中で提供して、利用者が横スクロールをしなくてもテキストの行を読めるようにする

適用(対象)

スタイル切り替えをサポートしている全てのウェブコンテンツ技術

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

解説

制作者は、横スクロールを必要とするようなレイアウトを使用することがある。その場合でも、横スクロールを必要とせずに1行のテキストを読めるレイアウトに切り替えるオプションをコンテンツ内で提供することで、達成基準を満たすことができる。これは、標準的なスタイル切り替えの技術を用いることで達成できる。

コンテンツにアクセスするために横スクロールが必要であっても、1行のテキストを読む際に横スクロールが必要ないようにコンテンツをレイアウトしている場合は、達成基準を満たすことに注意すること。

例えば、スプレッドシートで横スクロールを必要とするが、個々の列内で横スクロールが必要ないような場合は許容される(すなわち、他の列を見るためだけにスクロールが必要で、個々の列の左端や右端を表示するのにスクロールを必要としないような場合)。

注記: この達成方法は、適合していないなコンテンツに代わって適合している代替版のページを表示させるためのスタイル切り替え技術と組み合わせて使うこともできる。詳細は、C29: 適合している代替版を提供するために、スタイル・スイッチャーを使用する 及び 適合している代替版を理解する を参照のこと。

事例

事例 1

不動産会社がオンラインのアニュアルレポートを印刷版と同じレイアウトで提供していて、1行のテキストを読むために横スクロールを必要としている。スタイルシートを切り替えるコントロールがページにあり、横スクロールを必要としないレイアウトを提供している。

事例 2

金融のスプレッドシートがオンラインにある。1月の住宅市場の動向がテキストで説明されている。右側の画面外に、9月の住宅市場の動向を説明した列がある。利用者は9月エリアに右スクロールでき、ウィンドウ幅が最大の時に、更に横スクロールをしなくてもその列にある全てのテキストが読める。

検証

チェックポイント
  1. 最大ウィンドウ幅で横スクロールが必要なコンテンツを開く。

  2. 1行のテキストを読むために横スクロールが不要になるように切り替えられるオプションがコンテンツに含まれている。

  3. そのオプションを有効にする。

  4. すべての行のテキストを読むために横スクロールが必要ないことを確認する。

判定基準
  • 2. 及び 4. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


2. HTMLとXHTMLの達成方法


H2: 隣り合った画像とテキストリンクを同じリンクの中に入れる

適用(対象)

リンク機能を提供する HTML4、HTML5 及び XTHML ドキュメント

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

解説

この達成方法の目的は、テキストとアイコンの両方でリンクを提供する際、キーボード利用者や支援技術の利用者にとって混乱や困難を招くような ウェブページを作らないようにすることである。様々な利用者がテキストとアイコンを使いやすいと見出していることから、両方を提供することでリンクのアクセシビリティを向上させることができる。

よくあるリンクとして、テキストとアイコンの両方が互いに隣接しながらも、別々の要素としてレンダリングされているものがある。視覚的にはそれらは単一のリンクのように見えるが、それらを同様のリンクが隣接しているものとして受け取る利用者も多い。キーボード利用者の場合、冗長なリンクを通過していくのは面倒である。支援技術の利用者にとって、連続する同様のリンクに遭遇すると混乱する可能性がある。アイコンの代替テキストがリンクテキストの複製である場合、スクリーンリーダーは読み上げを2度繰り返すことになる。

制作者がリンク画像の代替テキストを省略した場合、代替テキストが視覚的なリンクと同じ目的を果たさないため、達成基準 1.1.1を満たせなくなる。

この達成方法は、テキストと画像を 1 つの a 要素にまとめ、イメージに空の代替テキストを指定してテキストの重複を排除することによって、混乱や困難がないリンクを提供するものである。このようにすることで、リンクにおける両方の表現が提供されつつも、キーボード利用者にとってリンクは1つだけとなり、ウェブページのリンク先リストを利用者に提供する補助技術も重複リンクを含まなくなる。

ページをレイアウトしやすくするために、テキストとアイコンのリンクを隣接したテーブルセルに分けることがある。WCAG 2.0 ではレイアウトテーブルの使用を禁止していないが、HTML の table 要素に定義されたセマンティックな意味を保持させ、コンテンツから表現を分離するコーティング手法に準拠するためにも、CSS ベースのレイアウトが推奨されている。CSS が使用されている場合には、この達成方法を適用して、テキストとアイコンのリンクを一つにまとめることができる。

事例

事例 1

アイコンとテキストが同じ a 要素の中にある。(HTML4 又は HTML5)

コード例:

 <a href="products.html">
   <img src="icon.gif" alt="">
   製品のページ
 </a>      
事例 2

リンクにアイコンとテキストがあり、サイトのヘルプでそのアイコンの説明をしている。img 要素には、サイトのヘルプで使われているアイコンの名前(「HOMEページのアイコン」)が代替テキストとして記述されていて、サイトのヘルプの中では「HOMEページのアイコン」をクリックすることが説明されている。(HTML4 又は HTML5)

コード例:

<a href="home.html">
  <img src="house.gif" alt="HOMEページのアイコン">
  HOMEページへ戻る
</a>     

参考リソース

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

検証

チェックポイント

この達成方法を適用しているすべての a 要素に対して:

  1. a 要素に含まれるすべての img 要素の alt 属性値が空に設定されていることを確認する。

  2. a 要素に空の alt 属性値またはリンクテキストを補足し画像を説明する値を持つ img 要素が含まれていることを確認する

判定基準
  • 上記の全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H4: リンク、フォームのコントロール、およびオブジェクトには、論理的なタブ移動順序を作成する

適用(対象)

HTML 及び XHTML

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

解説

この達成方法の目的は、初期設定のタブ順番が十分でない時に、論理的なタブ順番を提供することである。 多くの場合、「G59: コンテンツ内の順番及び関係に従った順序で、インタラクティブな要素を配置する」を用いることで十分であり、この達成方法は必要ではない。表示とは異なるタブ順番を設定すると、ユーザビリティ上の不具合を生じさせる可能性が高くなる。

場合によって、コンテンツ制作者はコード内のインタラクティブな要素の順番に従うことなく、コンテンツの関係をたどるタブ順番を指定しようとするかもしれない。この場合、インタラクティブな要素のtabindex属性を使用することで選択肢の順番を指定できる。tabindex属性には、0 から 32767 の間の値を付与する。

インタラクティブな要素がタブキーを使ってナビゲートされる時、要素はtabindex属性の値の増える順にフォーカスが与えられる。0 よりも大きなtabindex値を持つ要素は、tabindexがない又は 0 のtabindexの要素の前にフォーカスを受けることになる。0 よりも大きな tabindexを持つ全ての要素がフォーカスを受け取った後、残りのインタラクティブな要素はウェブページに現れる順番でフォーカスが与えられる。

事例

事例 1

系図の検索フォームで結婚記録を検索する。検索フォームには花嫁及び花婿用のいくつかの入力フィールドがある。フォームは、データテーブルを用いてマークアップされ、1列目に花婿、2列目に花嫁のフィールドがある。コンテンツの順番は行ごとであるが、コンテンツ制作者はフォームを列ごとにナビゲートする方がより論理的であると感じている。この方法では、全ての花婿の条件は花嫁の条件へ移る前に記入できる。入力フィールドの tabindex 属性は、列ごとにナビゲートするタブ順番を指定するのに使用される。

コード例:

<form action="#" method="post">
 <table summary="1列目に花婿の検索条件、2列目に花嫁の検索条件がある">
  <caption>結婚記録の検索</caption>
  <tr>
   <th>検索基準</th>
   <th>花婿</th>
   <th>花嫁</th>
  </tr>
  <tr>
   <th>名</th>
   <td><input type="text" size="30" value="" name="groomfirst" 
        title="花婿の名" tabindex="1"></td>
   <td><input type="text" size="30" value="" name="bridefirst" 
        title="花嫁の名" tabindex="4"></td>
  </tr>
  <tr>
   <th>姓</th>
   <td><input type="text" size="30" value="" name="groomlast" 
        title="花婿の姓" tabindex="2"></td>
   <td><input type="text" size="30" value="" name="bridelast" 
        title="花嫁の姓" tabindex="5"></td>
  </tr>
  <tr>
   <th>出生地</th>
   <td><input type="text" size="30" value="" name="groombirth" 
        title="花婿の出生地" tabindex="3"></td>
   <td><input type="text" size="30" value="" name="bridebirth" 
        title="花嫁の出生地" tabindex="6"></td>
  </tr>
 </table>
</form>
事例 2

ウェブページは上部の右端に検索フィールドを提供している。コンテンツの順番が最初ではないが、タブ順番が最初になるようにフィールドには tabindex="1" が与えられている。

事例 3

tabindex 値は、連続した番号である必要はなく、特定の値で始まる必要もない。値は一意的である必要もない。同じ tabindex 値を持つ要素は、その文字の出現順にナビゲートされる。

タブ順番がコンテンツ順番に従っているコンテンツのセクションにおいて、個々の要素に異なるtabindex値を指定するよりも, 全ての要素に同じ値を与えることでエラーを起こりにくくすることが可能である。それらの要素を再配列する、又は新しい要素を加える、及び論理的なタブ順番を設定することは容易である。

コード例:

 <a href="xxx" tabindex = "1">リストの1番目のリンク</a>
 <a href="xxx" tabindex = "1">リストの2番目のリンク</a>
 <a href="xxx" tabindex = "1">初めにリストが作られて大分たってから追加されたリンク</a>
 <a href="xxx" tabindex = "1">リストの3番目のリンク</a>
 ...
 <a href="xxx" tabindex = "1">リストの20番目のリンク</a> 

参考リソース

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

検証

チェックポイント
  1. tabindex が使われている。

  2. tabindex が使われているならば、tabindex 属性により指定されたタブ順番がコンテンツの関係に従っている。

判定基準
  • 2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H24: イメージマップの area 要素に代替テキストを提供する

適用(対象)

area要素を含むHTML及びXHTMLドキュメント

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

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

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

解説

この達成方法の目的は、イメージマップ上の選択可能領域と同じ役割を果たす代替テキストを提供することである。イメージマップは、area要素によって定義された選択可能領域によって分割されている1枚の画像である。各領域は、他のウェブページや、現在のウェブページ内の他の場所へのリンクである。各area要素のalt属性は、その画像の選択可能領域と同じ目的を果たすものである。

事例

事例 1

この事例では、イメージマップ上の各領域の目的を示したテキストを提供するのに、area要素のalt属性を利用している。

コード例:

<img src="welcome.gif" usemap="#map1" 
    alt="図書館の各エリア。詳細を見るには、各エリアを選択してください。" /> 
<map id="map1" name="map1">
  <area shape="rect" coords="0,0,30,30"
    href="reference.html" alt="資料室" />
  <area shape="rect" coords="34,34,100,100"
    href="media.html" alt="視聴覚室" />
</map>

参考リソース

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

検証

チェックポイント

イメージマップ上の各area要素について:

  1. そのarea要素にalt属性を指定している。

  2. alt属性で指定した代替テキストが、area要素で定義したイメージマップ上の領域と同じ目的を果たしている。

判定基準
  • 上記全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

HTML 及び XHTML

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

解説

この達成方法の目的は、フレームセットの個々のフレームに含まれるものを含む全てのHTML及びXHTMLドキュメントにおいて、head要素のセクション内でtitle要素を用いてドキュメントの目的を簡単な文言で定義することである。これにより、ページの本文でオリエンテーション情報を探すことなく、利用者はサイト内の自分のいる場所を素早く見つけることができる。

ドキュメント内で一度しか現れない(必須の)title要素は、ほとんど全てのHTML及びXHTMLの要素で利用されるかもしれないtitle属性と異なることに注意する。

事例

事例 1

この事例はドキュメントのタイトルを定義している。

コード例:


		<html xmlns="http://www.w3.org/1999/xhtml">
		   <head>
		      <title>ワールドワイドウェブコンソーシアム</title>
		   </head>
		   <body>
		      ...
		   </body>
		</html>

参考リソース

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

検証

チェックポイント
  1. HTML又はXHTMLドキュメントのソースコードに、head 要素内に空でないtitle要素がある。

  2. title 要素がドキュメントを説明している。

判定基準
  • 1.及び2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H28: abbr要素を用いて、略語の定義を提供する

適用(対象)

HTML 及び XHTML

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

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

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

解説

この達成方法の目的は、abbr 要素を用いることで、略語に対して元の語又は定義を提供することである

abbr 要素は、頭字語や頭文字語を含むあらゆる略語に用いてよい。HTML4 及び XHTML では、頭文字語や頭字語は acronym 要素を用いてマークアップすることもできる。abbr要素は、頭字語や頭文字語を含むあらゆる略語に用いてよい。HTML5 以降では、より一般的な abbr 要素の利用が提案され、acronym 要素は廃止されている。

事例

事例 1: abbr 要素を用いて略語の元の語を示す

コード例:

<p>普通、砂糖は 5 <abbr title="pound">lb.<abbr> の袋入りで売られている。</p>
<p><abbr title="World Wide Web">WWW</abbr> へようこそ!</p> 
事例 2: abbr 要素を用いて略語の定義を示す

コード例:

<p>タシニ <abbr title="及びその他">et al.</abbr> <abbr title="対">v.</abbr>
ニューヨーク・タイムズ紙 <abbr title="及びその他">et al.</abbr> は、全米著述業組合
による象徴的な訴訟事件であり……</p> 
事例 3: abbr 要素を用いて頭字語の元の語を示す

コード例:

<p><abbr title="Keep It Simple Stupid">KISS</abbr>の使用が…の間で広まってきた。</p> 
事例 4: abbr 要素を用いて頭文字語の元の語を示す

コード例:

<p><abbr title="World Wide Web">WWW</abbr></p> 

参考リソース

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

検証

チェックポイント
  1. 略語それぞれに、abbr 要素で元の語や定義を指定している。

判定基準
  • 1.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


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

適用(対象)

リンク(<a href> 要素)を含むHTML及びXHTMLドキュメント

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

解説

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

画像がリンクの唯一のコンテンツであるとき、画像の代替テキストがそのリンクに固有の機能を説明している。

リンクのコンテンツがテキスト及び一つ又はそれ以上の画像を含むとき、テキストがリンクの目的を十分に説明しているならば、画像の代替テキストは空にする。(H67: 支援技術が無視すべき画像の img 要素で、alt 属性値を空にして、title 属性を付与しない (HTML) を参照。) 画像がリンクの目的以外にも情報を伝えるときには、画像に適切な代替テキストも付与しなければならない。

事例

事例 1

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

コード例:

<a href="routes.html">
  ボールダーズクライミングジムでの現状のルート
</a>
事例 2

画像のリンクの目的を説明するために、img 要素に alt 属性を使用する。

コード例:

<a href="routes.html">
   <img src="topo.gif" alt="ボールダーズクライミングジムでの現状のルート" />
</a>
事例 3

アンカー (a) 要素が img 要素に加えてリンクの目的を説明するテキストを含むときは、空のalt属性を使用する。 リンクテキストはページ上で画像の隣りに表示されることに注意する。

コード例:

<a href="routes.html">
  <img src="topo.gif" alt="" />
  ボールダーズクライミングジムでの現状のルート
</a>
事例 4

サイトでは、製品の詳細ページの「フィードバック」リンクをクリックすることで、利用者がログインしたときに製品に関するフィードバックを提供することができる。他の利用者又は製品メーカーは、フィードバックに応答することができる。フィードバックのリンクは、利用者のフィードバックへの応答が利用可能な場合に、「フィードバック」テキストの前にアイコンを表示する。ヘルプ情報は、このアイコンを二重引用符を含む吹き出しとして説明し、アイコン自体を例として示している。 ヘルプテキストにおけるアイコンのテキストによる代替は、「応答受信アイコン」である。複数のモダリティを使用してこのアイコンを識別できるように、製品の詳細ページ(応答が利用可能な場合)で同じテキストによる代替が使用される。

コード例:

<a href="prod_123_feedback.htm">Feedback 
<img src="response.gif" width="15" height="15" alt="レスポンス受信アイコン" /></a>
事例 5

リンクはテキスト及びアイコンを含み、アイコンはリンク先についての追加情報を提供している。

コード例:

<a href="WMFP.pdf">
ウッドエンドミュージックフェスティバルのプログラム
<img src="pdficon.gif" alt="PDFファイル"/>
</a>
事例 6

MyCorp 社の年次レポートは企業のウェブサイト上から PDF ファイルとして入手でき、年次企業予算は Excel ファイルとして入手できる。

注記: 多くの利用者は、ファイルを開く際に新しいアプリケーションが開く場合は、あらかじめファイルの種類を知りたいので、このような追加情報を含めるのはしばしば便利であると考えられる。 ただし、この達成基準を満たすには必須ではない。

コード例:

<p>
<a href=”2009mycorp_report.pdf”>MyCorp 2009 年次レポート (pdf)</a><br />
<a href=”2009mycorp_budget.xls”>MyCorp 2009 年次予算 (Excel)</a>
</p>
事例 7

HTML5 においてブロックレベル要素をリンクで囲む。

コード例:

<article>
<a href="news.html">
<h3>議会で続く予算討議</h3>
<p class="subhead"><img class="alertimg" src="alerticon.png" alt="ニュース速報" height="30" width="30">議会の議員は、来年の予算をめぐる3つの挑戦的な問題について、激しい議論を続けた。</p>
<p>もっと読む</p>
</a>
</article>

ブロックレベル要素をリンクで囲む実例を示す。

参考リソース

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

検証

チェックポイント

この達成方法を使用したコンテンツのそれぞれのリンクに対して:

  1. テキスト又は非テキストコンテンツの代替テキストが a 要素に含まれている。

  2. img 要素だけが a 要素のコンテンツである場合、img要素の代替テキストがリンクの目的を説明している。

  3. a 要素が一つ又はそれ以上の img 要素を含み、img 要素の代替テキストが 空の場合、リンクのテキストがリンクの目的を説明している。

  4. a 要素がテキストのみを含んでいる場合、テキストがリンクの目的を説明している。

判定基準
  • 上記のすべてを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H32: 実行ボタンを提供する

適用(対象)

フォームのコントロールを含むコンテンツ

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

解説

この達成方法の目的は、利用者が状況の変化を明示的に要求できるメカニズムを提供することである。送信ボタンの本来の使用法は、フォームに入力されたデータを実行するHTTPリクエストを生成することである。それは、状況の変化を起こすために使われる適切なコントロールである。

事例

事例 1

これは送信ボタンを持つフォームの基本的な事例である。

コード例:

<form action="http://www.example.com/cgi/subscribe/" method="post"><br /> 
<p>メールリングリストに登録したい場合は、あなたの
メールアドレスを入力してください。</p><br /> 
<label for="address">eメールアドレスを入力してください。:</label>
<input type="text" id="address" name="address" /> 
<input type="submit" value="登録" /><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" /><br /> 
</form>  

参考リソース

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

検証

チェックポイント
  1. コンテンツ内の全てのフォームを見る。

  2. それぞれのフォームに、送信ボタン(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) を利用することが望ましい。

事例

事例 1: リンクの目的を明らかにする

コード例:

<a href="http://example.com/WORLD/africa/kenya.elephants.ap/index.html" 
title="象の避難の失敗について続きを読む">
巨大な荷物のせいで、避難はさんざんな結果に
</a> 

参考リソース

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

検証

チェックポイント

a 要素のソースコードについて、次のことを調べる。

  1. title 属性のある a 要素では、リンクテキストの文言とともに title 属性がそのリンクの目的を示している。

判定基準
  • 1.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H34: インラインでテキストの方向を混在させるために、Unicode の RLM 文字又は LRM 文字を使用する

適用(対象)

HTML 及び XHTML

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

解説

この達成方法の目的は、HTMLの双方向性アルゴリズムが望ましくない結果を生じるとき時に、それを無効にするためにUnicode制御文字のright-to-left markとleft-to-right markを用いることである。たとえば、スペース又は句読点のようなニュートラルな文字が異なる方向性のテキストの間に置かれている 時に必要となることがある。この達成方法で用いられているコンセプトは、W3C文書の「What you need to know about the bidi algorithm and inline markup(双方向アルゴリズムとインラインマークアップを知るために必要なこと)」に書かれている。

Unicode 制御文字のright-to-left mark及びleft-to-right markは、以下に示すように、 そのまま、又は文字符号か数字符号の参照によって挿入することが可能である。

  • left-to-right mark(LRM): &lrm; 又は &#x200e; (U+200E)

  • right-to-left mark(RLM): &rlm; 又は &#x200f; (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.

参考リソース

検証

チェックポイント
  1. テキストの方向が変わっている箇所のソースを調べる。

  2. テキストの方向が変わっている際には、スペース又は句読点のようなニュートラルな文字が初期設定ではない方向で表示されたテキストに隣接している。

  3. 上記2.に該当し、かつHTMLの双方向性のアルゴリズムがニュートラルな文字の誤った配列を生み出している場合、ニュートラルな文字の直後にUnicode制御文字の right-to-left又はleft-to-right markがあり、ニュートラルな文字を前の文字列の一部として配置させている。

判定基準
  • 3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H35: applet 要素に代替テキストを提供する

適用(対象)

applet要素が非推奨ではない場合に、Javaアプレットを読み込んでいるHTML及びXHTMLドキュメント

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

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

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

解説

この達成方法の目的は、アプレットのラベルを提供するalt属性を用いること及びapplet要素のボディに代替テキストを提供することによって、アプレットに対する代替テキストを提供することである。この達成方法では、ユーザエージェントごとに、alt属性及びapplet要素のボディのサポート状況が異なるため、両方のメカニズムを必要としている。

事例

事例 1: 三目並べゲームのアプレット

コード例:

<applet code="tictactoe.class" width="250" height="250" alt="三目並べゲーム">
   三目並べゲーム
</applet> 

検証

チェックポイント
  1. applet要素のソースコードを見る。

  2. アプレットに対する代替テキストがapplet要素のalt属性にある

  3. アプレットに対する代替テキストがapplet要素のボディの中にある。

判定基準
  • 2.及び3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H36: 送信 / 実行ボタンとして用いる画像の alt 属性を使用する

適用(対象)

画像の送信/実行ボタンを使用するコンテンツに適用する。

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

解説

この達成方法の目的は、type属性が「image」であるinput要素において、input要素のalt属性を機能的なラベルを提供するのに使用することである。このラベルは、画像の説明をするのではなく、ボタンの機能を説明する。もしそのページに、それぞれ異なる結果につながる複数の送信/実行ボタンがあるならば、ラベルは特に重要である。

input要素は、多くの種類のフォームのコントロールを作成するのに使用される。HTML及びXHTMLのDTDでは、これら全てでalt属性を用いることができるが、本来は画像の送信/実行ボタンだけに使用すべきである。ユーザエージェントでは、他の種類のフォームのコントロールでのalt属性の使用をサポートしていないため、これらのコントロールをラベル付けするために他のメカニズムを用いている。

事例

事例 1

alt 属性がある input 要素

コード例:

<form action="http://example.com/prog/text-read" method="post">

  <input type="image" name="submit" src="button.gif" alt="送信/実行" />
</form> 

参考リソース

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

検証

チェックポイント
  1. type 属性の値が「image」であるすべての input 要素に、alt属性がある。

  2. その alt 属性がボタンの機能を説明している。

判定基準
  • 1.及び2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H37: img 要素の alt 属性を使用する

適用(対象)

HTMLドキュメントで用いられている画像

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

解説

img要素を使用するときは、簡潔な代替テキストをalt属性に指定する。注記:この属性の値は「ALTテキスト」ともいう。

画像がコンテンツを理解するために重要な文字を含むとき、代替テキストにはそれらの文字を含めなくてはならない。これにより、代替テキストはページ上で画像と同じ役割を果たすことができる。 代替テキストは、画像自体の視覚的な特徴を説明する必要はないが、画像と同じ意味を伝えなければらないことに注意する。

事例

事例 1

ウェブサイト上にある画像は、無料のニュースレターへのリンクである。画像は次のような文字を含んでいる:「無料のニュースレター:無料のレシピ、ニュースなどを入手しよう! 詳しくはこちら」 画像の代替テキストは、画像にある文字と一致している。

コード例:

<img src="newsletter.gif" alt="無料のニュースレター:
無料のレシピ、ニュースなどを入手しよう! 詳しくはこちら" />
事例 2

ウェブサイト上にある画像は、ビルの間取り図を表現している。その画像は、各部屋の部分がインタラクティブに操作できるイメージマップである。代替テキストは「ビルの間取り図。各部屋の目的又は内容に関する詳しい情報は、部屋を選択してください」である。 「部屋を選択してください」という指示により、画像がインタラクティブであることを示している。

参考リソース

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

HTML 4.01 IMG element

HTML 4.01 alt attribute

検証

チェックポイント
  1. コンテンツに含まれる img 要素それぞれを調べる。

  2. 意味を伝える img 要素それぞれが、alt 属性を含んでいる。

  3. 画像にコンテンツを理解するために重要な文字が含まれている場合、その文字が代替テキストに記述されている。

判定基準

2.及び3.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H39: データテーブルの表題とデータテーブルを関連付けるために、caption 要素を使用する

適用(対象)

HTML及びXHTMLのデータテーブル

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

解説

この達成方法の目的は、見た目でテーブルの表題を付ける場合に、プログラムで解釈できるようにデータテーブルと表題を関連付けることである。表題はテーブルの識別子であり、タイトル又は見出しのような働きをする。

caption 要素は表題のテキストのための適切なマークアップであり、(初期状態では)表示上も、テーブルの識別子がそのテーブルに関連付けられていることを保証するものである。さらに、caption 要素を用いることによって、音声読み上げソフトウェアがテーブルの表題に利用者を直接誘導することも可能になる。

caption 要素は、テーブルに summary 属性を指定しているかどうかに関わらず利用できる。caption 要素はテーブルを特定するもの、summary 属性はテーブルの概要を提供したり、見方を説明したりするものである。両方とも指定する場合、summary 属性に caption 要素と同じ情報を含めるべきではない。

注記: WCAG 2.0 はレイアウトテーブルの利用を禁止していないが、CSS ベースのレイアウトを推奨している。HTML 及び XHTML の table 要素に与えられたセマンティックな意義を守り、コンテンツから表現を分離するというコーディングの実践に沿うためである。テーブルをレイアウトのために利用する場合、caption 要素は使用しない。レイアウトテーブルの目的は、コンテンツの配置を制御することのみであって、テーブルそのものは利用者から見て「透明」であるべきである。caption 要素を用いることによってテーブルの存在を示してしまうと、この透明性を壊すことになる。F46: 達成基準 1.3.1 の失敗例 - レイアウトテーブルで、th 要素、caption 要素、又は空ではない summary 属性を使用しているを参照のこと。

事例

事例 1: スケジュールカレンダーの表題

コード例:

<table>
<caption>3月6日の週のスケジュール</caption>
...</table>

参考リソース

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

検証

チェックポイント

各データテーブルごとに:

  1. テーブルに caption 要素が含まれていることを確認する。

  2. caption 要素の内容がテーブルを識別しているかどうかを確認する。

判定基準
  • 1. 及び 2. を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H40: 記述リストを使用する

適用(対象)

HTML 及び XHTML

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

解説

この達成方法の目的は、名前または用語の説明を記述リストの形式で提供することである。リストは dl 要素を用いてマークアップし、その中では用語それぞれを個別の dt 要素に含め、直後の dd 要素に説明を含める。意味のある順序が確保されていれば、複数の用語を単一の説明に、単一の用語を複数の説明に関連付けることもできる。title 属性を用いて、記述リストに関する補足情報を提供することもできる。記述リストを使用することで、表現が変化しても、用語とその説明が 1 つの単位としてグループ化され、意味的な関連が保証される。

説明がアルファベット順に並べられている場合は、記述リストを使用するのが最も容易である。記述リストの一般的な使用法は用語集である。

注記: HTML5 では、「記述リスト」という名前が導入された。以前のバージョンでは、これらのリストは「定義リスト」と呼ばれていた。

事例

事例 1

海事用語の記述リストを、航海に関するウェブサイトで利用している。

コード例:

<dl title="海事用語">
  <dt>ノット</dt>
  <dd>
    <p><em>ノット</em>は、1時間当たり1海里の速度単位である
    (1時間当たり1.15マイルまたは1.852キロメートル)。</p>
  </dd>
  <dt>左舷</dt>
  <dd>
    <p><em>左舷</em>は、人間が船首(船の最前部)から見たときの、
    船体の左側を表す海事用語である(ボートや船に使用される)。</p>
  </dd>
  <dt>右舷</dt>
  <dd>
    <p><em>右舷</em>は、人間が船首(船の最前部)から見たときの、
    船体の右側を表す海事用語である(ボートや船に使用される)。</p>
  </dd>
</dl> 

参考リソース

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

検証

チェックポイント

用語とそれに関する説明の組み合わせについて:

  1. そのリストが、dl要素に含まれている。

  2. リストの各用語が dt 要素内に含まれていることを確認する。

  3. 同じ説明を共有する複数の用語があるときに互いの dt 要素が連続することを確認する。

  4. 各用語に対する説明が 1 つ以上の dd 要素に含まれていることを確認する。

  5. 用語を含む 1 つ以上の dt 要素の直後に、1 つ以上の dd 要素があることを確認する。

判定基準
  • 上記の全てを満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H42: 見出しを特定するために、h1 要素~ h6 要素を使用する

適用(対象)

HTML 及び XHTML

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

解説

この手法の目的は、HTML 及び XHTML の見出しマークアップを用いて、コンテンツの見出しにセマンティックなコードを提供することである。見出しマークアップは、支援技術がテキストの見出し状態を利用者に提示することを可能にする。スクリーンリーダーは、コードを認識し、そのレベル、ビープ音、又は他の聴覚インジケーターを備えた見出しとしてテキストをアナウンスすることができる。スクリーンリーダーはまた、見出しマークアップをナビゲートすることもできる。これは、スクリーンリーダー利用者が関心のあるコンテンツをより迅速に見つけるための効果的な方法である。オーサリングされた視覚表示を変更する支援技術はまた、見出しマークアップで識別できる見出しのための適切な代替視覚表示を提供することもできる。

事例

事例 1: 階層的な見出し構造

以下の事例では、h3h2 のサブセクションで、h2h1 のサブセクションとなっていて、見出しが階層的なレイアウトに用いられている。

コード例:

<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 要素でマークアップされている。3 段組のうち 1 番目と 3 番目のコンテンツは重要度が低いため、タイトルが h2 要素でマークアップされている。

注記: 以下のコード例は、ウェブページの特定のセクションに対して用いるべき見出しレベルを規定するものではないことに留意することが重要である。レイアウトする際には、各カラムの最初に見出しを同じ見出しレベル(例えば、h1)で提示したり、またはコード例にあるようにメインコンテンツに関してその重要度を反映した見出しレベルで提示したりすることが可能である。

コード例:

<head>
 <title>今日の株式市場</title>
 </head>

 <body>

 <!-- left nav -->
 <div class="left-nav">
 <h2>サイトナビゲーション</h2>
 <!-- content here -->
 </div>

 <!-- main contents -->
 <div class="main">
 <h1>今日の株式市場</h1>
 <!-- article text here -->
 </div>

 <!-- right panel -->
 <div class="left-nav">
 <h2>関連リンク</h2>
 <!-- content here -->
 </div>
 </body>

参考リソース

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

検証

チェックポイント
  1. コンテンツが見出しであるときに、見出しマークアップを利用している。

  2. コンテンツが見出しでないときは、見出しマークアップを利用していない。

判定基準
  • 1.及び2.を満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H43: データテーブルのデータセルを見出しセルと関連付けるために、id 属性及び headers 属性を使用する

適用(対象)

HTML 及び XHTML

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

解説

この達成方法の目的は、(データテーブル内の)各データセルを適切な見出しセルと関連付けることである。まず、各データセル(td要素)にheaders属性を付加する。次に、データセルの見出しとなるセルにはid属性を指定する。データセルのheaders属性で指定するのは、関連付けられる見出しセルのid属性値であり、2つ以上のidを含める場合はスペース区切りで列挙する。

この達成方法は、データセルを2つ以上の行見出し及び(又は)列見出しに関連付ける場合に利用する。こうすることで、th要素のみ、またはth要素にscope属性を付けただけでは、データセルと見出しセルの関係が複雑すぎて定義できない場合でも、スクリーンリーダーは各データセルと関連付けられている見出しセルを読み上げることができる。また、表現形式が変わったとしても、これらの複雑な関係を知覚しやすくなる。

この達成方法を、レイアウトテーブルに利用することは推奨しない。なぜなら、レイアウトのためにテーブルを利用する際には、意味がないにも関らず何らかの関係性を示してしまうことになるからである。

事例

事例 1: 行見出しが複数あるテーブル

コード例:

<table>
   <tr>
     <th rowspan="2" id="h">予習</th>
     <th colspan="3" id="e">試験</th>
     <th colspan="3" id="p">課題</th>
   </tr>
   <tr>
     <th id="e1" headers="e">1</th>
     <th id="e2" headers="e">2</th>
     <th id="ef" headers="e">最終</th>
     <th id="p1" headers="p">1</th>
     <th id="p2" headers="p">2</th>
     <th id="pf" headers="p">最終</th>
   </tr>
   <tr>
    <td headers="h">15%</td>
    <td headers="e 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> 

参考リソース

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

検証

チェックポイント
  1. レイアウトテーブルかどうかを確認、テーブルのセルの内容が同じ行や列に含まれる他セルの内容と関係があるかどうか判断する。「いいえ」の場合、そのテーブルはレイアウトテーブルである。「はい」の場合、そのテーブルはデータテーブルである。

  2. データテーブルである場合、2つ以上の行見出し及び(又は)列見出しと関連付けられているあらゆるデータセルのheaders属性に、関連付けられている全ての見出しセルのidを指定している。

  3. データテーブルでは、id属性またはheaders属性を指定しているあらゆるセルについて:

    1. データセルのheaders属性で指定した各idが、見出しセルのid属性値と一致している。

    2. データセルのheaders属性で、そのデータセルと関連付けられた全ての見出しのid属性値を指定している。

    3. 全てのidが一意的であり、重複して使用していない(つまり、ページの中で2つ以上の要素が同じidを持つことはできない)。

判定基準
  • レイアウトテーブルの場合、どのセルにもheaders属性又はid属性がない。

  • データテーブルで、id属性を指定した全てのセルについて、3.a、3.b、3.cを満たしている。

  • データテーブルで、2つ以上の行見出し及び(又は)列見出しと関連付けられた全てのデータセルについて、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"

事例

事例 1: テキスト入力フィールド

この事例では、テキスト入力フィールドに「お名前」という明示的なラベルが付けてある。label 要素の for 属性値は、input 要素の id 属性値と一致している。

コード例:

<label for="firstname">お名前:</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>ドーナツ</h1>

<p>お好きなドーナツを選び、「ドーナツを購入」ボタンを押してください。</p>

<form action="http://example.com/donut" method="post">
<p>
  <input type="radio" name="flavor" id="choc" value="chocolate" />
    <label for="choc">チョコレート</label><br/>
  <input type="radio" name="flavor" id="cream" value="cream"/>
    <label for="cream">クリーム入り</label><br/>
  <input type="radio" name="flavor" id="honey" value="honey"/>
    <label for="honey">ハニーがけ</label><br/>
  <input type="submit" value="ドーナツを購入"/>
</p>
</form> 

参考リソース

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

検証

チェックポイント

ウェブページ内の type="text"type="file"type="password" を指定した input 要素、textarea 要素、select 要素全てについて:

  1. input 要素、textarea 要素及び select 要素の前に、そのコントロールの目的が特定できる label 要素がある。

  2. label 要素の for 属性値が、input 要素、textarea 要素及び select 要素の id と一致している。

  3. label 要素のラベルが視覚的に認識できる状態である。

ウェブページ内の type="checkbox" 及び type="radio" を指定した input 要素全てについて:

  1. input 要素の後に、そのコントロールの目的が特定できる label 要素があるか確認する。

  2. label 要素の for 属性が、input 要素の id 属性と一致している。

  3. label 要素のラベルが視覚的に認識できる状態である。

判定基準
  • 1.及び2.を満たしている。達成基準 3.3.2 に関しては、3.も満たしている。

この達成方法が「十分な達成方法」の一つである場合、このチェックポイントや判定基準を満たしていなければ、それはこの達成方法が正しく用いられていないことを意味するが、必ずしも達成基準を満たしていないことにはならない。場合によっては、別の達成方法によってその達成基準が満たされていることもありうる。


H45: longdesc 属性を用いる

適用(対象)

短い代替テキストでは説明しきれない画像を含むHTML及びXHTML

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

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

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

解説

この達成方法の目的は、短い代替テキストでは画像の機能や情報が十分に伝達できない場合に、longdesc 属性でのファイル指定によって情報を提供することである。longdesc 属性には URI を指定する。これは非テキストコンテンツの詳しい説明を含む目的地を意味する。

制作者は、テキストを別のリソースまたはページ上の画像にテキストを含めることで、画像の説明を提供できる。別のリソースを用いて説明することの利点は、同じ画像を複数のインスタンスで簡単に再利用できることにあり、元となるドキュメントにページ上の視覚的なノイズを加えず、説明の最終点を利用者に明確にすることにある。画像と同じページに説明を提供する利点は、すべての利用者が説明にアクセスできることにある。ページ上のメソッドの制限は、複数の説明を単一の別ページに提供することと同様に、現在の longdesc 属性の実装サポートでは、長い説明文の最終点を識別できないということである。制作者はどこで説明文が終わるかを識別する定型文を提供することによって解決ができる。

事例

事例 1: longdesc 属性を用いて別のリソースに含まれた長い説明文を参照する。

コード例:

<p><img src="chart.gif" alt="複雑な図" longdesc="chartdesc.html"/></p> 
事例 2: longdesc 属性を用いて同じページに含まれた長い説明文を参照する。