意図
この達成基準の意図は、視覚的又は聴覚的な体裁によって暗に伝えられている情報及び関係性を、その提示形式が変わったときにも保つようにすることである。例えば、コンテンツがスクリーンリーダーによって読み上げられたり、コンテンツ制作者が提供するスタイルシートがユーザスタイルシートに置き換えられたりしたときには、提示形式が変わる。
目の見える利用者は、様々な視覚的な手がかりによって構造及び関係性を知覚する。例えば、見出しは多くの場合、改行で段落から切り離された、より大きな太字のフォントである。リスト項目は、中黒が先行しており、おそらく字下げがある。段落は、改行で分離される。共通の特性を持つ項目は、表の行と列で整理される。フォームのフィールドは、テキストラベルを共有するグループとして配置されることがある。異なる背景色を用いて、複数の項目が互いに関係のあることを示していることもある。特別な状態の語句は、フォントファミリーを変える及び/又は、太字、イタリック、下線付きにすることによって示されている。共通の特性を共有する項目は、同じ行又は列を共有するセルの関係性並びに、各セルと行及び/又は列見出しとの関係性を理解するのが不可欠な表に整理されている。などである。これらの構造及び関係性がプログラムによる解釈が可能する、又はテキストで入手可能にすることで、理解に重要な情報がすべての人に知覚されることを保証する。
同様に、聴覚的な手がかりを用いることもある。例えば、チャイム音が新しい節の開始位置を示している。声のピッチや発話のスピードを変えて、重要な情報を強調したり、引用されたテキストを示したりしている、など。
そういった関係性が、ある利用者にとって知覚可能であれば、その関係性をすべての利用者が知覚できるようにすることが可能である。情報をすべての利用者にきちんと提供できたかどうかを判断する一つの方法は、その情報に様々な感覚モダリティで連続してアクセスしてみることである。
用語集にある用語へのリンクを a 要素 (又は、使用している技術特有のリンク要素) を用いて実装して、異なるフォントで示していれば、スクリーンリーダーの利用者は、用語集にある用語のところで、たとえフォントの違いに関する情報は受け取れなかったとしても、それがリンクであることが音声読み上げを聞けば分かるだろう。あるオンラインカタログの価格表示では赤い大きなフォントを使用している。スクリーンリーダーの利用者は赤色の情報は得られないが、価格の前に通貨表示を記載することで情報を得ることができる。
ウェブコンテンツ技術の中には、ある種の情報及び関係性をプログラムによる解釈をするための手段を提供していないものがある。そういった場合には、その情報及び関係性を説明するテキストを提供すべきである。例えば、「アスタリスク (*) のある項目はすべて必須項目です。」のように説明テキストを提供する。テキストによる説明は、例えば、その親要素又は隣接する要素内などのように、(そのページを線形化したときに) テキストが説明している情報の近くに置くべきである。
場合によっては、関係性をプログラムによる解釈が可能にする又はテキストで提供することが望ましいかどうか、各自の判断に委ねるしかないこともありうる。しかし、技術がプログラムに基づいた関係性をサポートする場合、情報及び関係性をテキストで提供するよりも、プログラムによる解釈することを強く推奨する。
色の値がプログラムによる解釈が可能であることは要求していない。色によって伝えられる情報は、その値を明らかにするだけでは、十分に提示することができないからである。そのため、色に特有の問題については、達成基準 1.3.1 ではなく、達成基準 1.4.1 で対処している。
メリット
- この達成基準は、ユーザエージェントが個々の利用者のニーズに応じてコンテンツに適応できるようにすることによって、様々な障害のある利用者の役に立つ。
- 全盲の (スクリーンリーダーを使用している) 利用者が、色を用いて伝えられている情報をテキストでも得られるようになる (色を用いて情報を伝えている画像のテキストによる代替を含む)。
- 点字ピンディスプレイを使用している盲ろうの利用者は、色に依存した情報を利用できないことがある。
事例
必須項目のある入力フォーム
入力フォームに、いくつかの必須項目がある。必須項目のラベルを、赤で表示している。さらに、各ラベルの最後には、アスタリスクの記号文字 (*) が付いている。フォームへの入力に関する説明文には、「すべての必須項目は赤字で示してあり、アスタリスク (*) が付いています。」と書かれていて、例が後に続いている。
必須項目を示すために色とテキストを用いている入力フォーム
ある入力フォームには、必須項目と任意項目の両方がある。入力フォームの先頭にある説明文には、必須項目のラベルが赤字になっていて、「必須」というテキストによる代替のあるアイコンも付いている。赤字とアイコンの両方が、フォームのテキストフィールドとプログラム的に関連付けられているので、支援技術の利用者は必須項目を判断できる。
各セルの見出しをプログラムによる解釈が可能なバスの時刻表テーブル
バスの運行スケジュールが、1 列目には縦にバス停の名前が並び、1 行目には横に異なるバスが並んでいる表で示されている。各セルには、バスがそのバス停に到着する時刻が書かれている。支援技術が、各セルにある時刻がどのバスとどのバス停とに関連付けられているのかをプログラムによる解釈が可能であるように、各バス停と各バスのセルは、それぞれの対応する行又は列の見出しとして示されている。
チェックボックスのラベルをプログラムによる解釈が可能な入力フォーム
あるフォームでは、各チェックボックスに対するラベルが、支援技術によってプログラムによる解釈が可能になっている。
テキスト文書
あるシンプルなテキスト文書は、タイトルの前に 2 行の空白行、リスト項目を示すアスタリスク、及びその他の標準的な書式の慣習で体裁が整えられているため、その構造はプログラムによる解釈が可能となる。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成方法
この節にある番号付きの各項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組み合わせを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。その他の達成方法についての詳細は、WCAG 達成基準の達成方法を理解するの「その他の達成方法」を参照のこと。
十分な達成方法
そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の達成方法 (又は、達成方法の組み合わせ) がある。
状況 A: ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムによる解釈が可能になるセマンテックな構造を提供している場合:
- ARIA11: ページのリージョンを特定するために ARIA ランドマークを使用する
- ARIA12: 見出しを特定するために role=heading を使用する
- ARIA13: リージョンとランドマークに名前 (name) を付けるために、aria-labelledby を使用する
- ARIA16: ユーザインタフェース コントロールの名前 (name) を提供するために、aria-labelledby を使用する
- ARIA17: 関連するフォームコントロールを特定するために、グルーピングロールを使用する
- ARIA20: ページのリージョンを特定するために region ロールを使用する
- G115: 構造をマークアップするために、セマンティックな要素を使用する、かつ、H49: 強調又は特別なテキストをマークアップするために、セマンティックなマークアップを使用する
- G117: テキストの提示のバリエーションによって伝えている情報を伝達するために、テキストを使用する
- G140: 異なる提示を可能にするために、情報と構造を表現から分離する
- ARIA24: アイコンフォントを意味的に識別するために role="img" を使用する
次の達成方法を用いて、表現によって伝えられている情報及び関係性をプログラムによる解釈が可能になる:
- G138: 色の手がかりを用いるときは必ず、セマンティックなマークアップを使用する
- H51: 表形式の情報を提示するために、テーブルのマークアップを使用する
- PDF6: PDF 文書でテーブルのマークアップにテーブル要素を使用する
- PDF20: 間違ってタグ付けされているテーブルを修復するために、Adobe Acrobat Pro のテーブルエディタを使用する
- H39: データテーブルのキャプションとデータテーブルを関連付けるために、caption 要素を使用する
- H73: データテーブルの概要を提供するために、table 要素の summary 属性を使用する
- H63: データテーブルで見出しセルとデータセルを関連付けるために、scope 属性を使用する
- H43: データテーブルのデータセルを見出しセルと関連付けるために、id 属性及び headers 属性を使用する
- H44: テキストラベルとフォームコントロールを関連付けるために、label 要素を使用する
- H65: label 要素を使用できない場合に、フォームコントロールを特定するために、title 属性を使用する
- PDF10: PDF 文書内のインタラクティブなフォームコントロールにラベルを付ける
- PDF12: PDF 文書内のフォームフィールドの名前 (name)、役割 (role)、値 (value) 情報を提供する
- H71: fieldset 要素及び legend 要素を使用して、フォームコントロールのグループに関する説明を提供する
- H85: select 要素内の option 要素をグループ化するために、optgroup 要素を使用する
- H48: リスト又はリンクのグループに、ol 要素、ul 要素、dl 要素を用いる
- H42: 見出しを特定するために、h1 要素~ h6 要素を使用する
- PDF9: PDF 文書内のコンテンツを見出しタグでマークアップすることによって見出しを作成する
- SCR21: ページにコンテンツを追加するために、Document Object Model (DOM) の機能を使用する
- PDF11: PDF 文書内で Link アノテーションと /Link 構造要素を使用してリンクとリンクテキストを提供する
- PDF17: PDF 文書に一貫性のあるページ番号を指定する
- PDF21: PDF 文書内のリストにリストタグを使用する
- H97: nav 要素を使用して、関連したリンクをグループ化する
状況 B: ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムによる解釈が可能になるセマンテックな構造を提供していない場合:
- G117: テキストの提示のバリエーションによって伝えている情報を伝達するために、テキストを使用する
表現によって伝えられている情報及び関係性をプログラムによる解釈が可能になる、又は次の達成方法を用いてテキストで入手可能にする:
参考達成方法
適合のために必須ではないが、コンテンツをよりアクセシブルにするために、次の追加の達成方法を検討することが望ましい。ただし、すべての状況において、すべての達成方法が使用可能、又は効果的であるとは限らない。
失敗例
以下に挙げるものは、WCAG ワーキンググループが達成基準の失敗例とみなした、よくある間違いである。
- F2: 達成基準 1.3.1 の失敗例 - 情報を伝えるために、適切なマークアップ又はテキストを用いずに、テキストの提示の変化を使用している
- F33: 達成基準 1.3.1 及び達成基準 1.3.2 の失敗例 - プレーンテキストのコンテンツで複数の段組みを作成するために、空白文字を使用している
- F34: 達成基準 1.3.1 及び達成基準 1.3.2 の失敗例 - プレーンテキストのコンテンツでテーブルの書式を整えるために、空白文字を使用している
- F42: 達成基準 1.3.1、達成基準 2.1.1、達成基準 2.1.3、又は達成基準 4.1.2 の失敗例 - リンクをエミュレートしている
- F43: 達成基準 1.3.1 の失敗例 - コンテンツにおける関係を表さない方法で、構造的なマークアップを使用している
- F46: 達成基準 1.3.1 の失敗例 - レイアウトテーブルで、th 要素、caption 要素、又は空ではない summary 属性を使用している
- F48: 達成基準 1.3.1 の失敗例 - 表形式の情報をマークアップするために、pre 要素を使用している
- F87: 達成基準 1.3.1 の失敗例 - CSS の ::before 及び ::after 疑似要素並びに 'content' プロパティを用いて、非装飾のコンテンツを挿入している
- F90: 達成基準 1.3.1 の失敗例 - headers 属性及び id 属性によってテーブルの見出しとコンテンツが不正確に関連付けられている
- F91: 達成基準 1.3.1 の失敗例 - テーブルの見出しを正しくマークアップしていない
- F92: 達成基準 1.3.1 の失敗例 - セマンティックな情報を伝えるコンテンツに presentation ロールを使用している
重要な用語
障害のある利用者の要件を満たすために、主流のユーザエージェントが提供する機能を超えた機能を提供するような、ユーザエージェントとして動作する、又は主流のユーザエージェントと共に動作するハードウェア及び/又はソフトウェア。
支援技術が提供する機能としては、代替の提示 (例: 合成音声や拡大表示したコンテンツ)、代替入力手法 (例: 音声認識)、付加的なナビゲーション又は位置確認のメカニズム、及びコンテンツ変換 (例: テーブルをよりアクセシブルにするもの) などを挙げることができる。
支援技術は、API を利用、監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。
主流のユーザエージェントと支援技術との区別は、絶対的なものではない。多くの主流のユーザエージェントは、障害のある個人を支援する機能を提供している。基本的な差異は、主流のユーザエージェントが障害のある人もない人も含めて、広く多様な利用者を対象にしているのに対し、支援技術は、特定の障害のある利用者という、より狭く限られた人たちを対象にしているということである。支援技術により提供される支援は、対象とする利用者に特化した、よりニーズに適したものである。主流のユーザエージェントは、プログラムオブジェクトからのウェブコンテンツの抽出、マークアップの識別可能な構造への解釈といった、重要な機能を支援技術に対して提供する場合がある。
この文書の文脈において重要な支援技術としては、以下のものが挙げられる:
- 画面拡大ソフト及びその他の視覚的な表示に関する支援技術。視覚障害、知覚障害、及び読書困難などの障害のある人が、レンダリング後のテキスト及び画像の視覚的な読みやすさを改善するために、テキストのフォント、サイズ、間隔、色、音声との同期などを変更するのに使用している。
- スクリーンリーダー。全盲の人がテキスト情報を合成音声あるいは点字で読み取るために使用している。
- 音声変換ソフトウェア。認知障害、言語障害、及び学習障害のある人が、テキストを合成音声に変換するために使用している。
- 音声認識ソフトウェア。何らかの身体障害のある利用者が使用することがある。
- 代替キーボード。特定の身体障害のある人がキーボード操作をシミュレートするのに使用している (ヘッドポインタ、シングルスイッチ、呼気・吸気スイッチ、及びその他の特別な入力デバイスを使った代替キーボードを含む)。
- 代替ポインティングデバイス。特定の身体障害のある人がマウスポインタとボタンの動きをシミュレートするのに使用している。
コンテンツの構造、提示、及びインタラクションを定義するコード又はマークアップも含めて、ユーザエージェントによって利用者に伝達される情報及び感覚的な体験。
利用者が知覚できる形式でコンテンツをレンダリングすること。
支援技術を含む様々なユーザエージェントが抽出でき、利用者に様々な感覚モダリティで提示できるような形のデータがコンテンツ制作者によって提供されたとき、そのデータがソフトウェアによって解釈されること。
マークアップ言語で、一般に入手可能な支援技術が直接アクセスできる要素と属性から解釈される。
非マークアップ言語の技術特有のデータ構造から解釈され、一般に入手可能な支援技術がサポートするアクセシビリティ API を通じて支援技術に提供される。
コンテンツの異なる部分間における意味のあるつながり。
ウェブコンテンツを取得して利用者に提示するあらゆるソフトウェア。
ウェブコンテンツの取得、レンダリング及びインタラクションを支援する、ウェブブラウザ、メディアプレーヤ、プラグイン、及びその他のプログラム (支援技術も含む)。
単一の URI から HTTP で得た埋め込まれていないリソースに加え、レンダリングに使われる、又はユーザエージェントがこのリソースと一緒にレンダリングすることを意図しているその他のあらゆるリソースを合わせたもの。
どのような「その他のリソース」も主たるリソースと一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされるとは限らない。
このガイドラインの適合範囲に含まれる対象となるウェブページとみなされるためには、リソースが「埋め込まれていない」リソースでなければならない。
単体のウェブリソースであり、埋め込まれている画像及びメディアのすべてを含んだもの。
Asynchronous JavaScript and XML (AJAX) を用いたウェブメールのプログラム。そのプログラム全体は http://example.com/mail に存在しているが、受信トレイ、連絡先、カレンダーがある。受信トレイ、連絡先、又はカレンダーを表示するリンク又はボタンが提供されているが、全体としてページの URI は変更されない。
カスタマイズ可能なポータルサイトで、利用者が様々なコンテンツモジュールのセットから表示させるコンテンツを選択できるようなもの。
ブラウザで "http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは 1 ページだけのウェブサイトかもしれないし、ウェブサイトの中のほんの 1 ページなのかもしれない。