情報及び関係性:
達成基準 1.3.1 を理解する
この達成基準の意図
この達成基準の意図は、視覚的又は聴覚的な体裁によって暗に伝えられている情報及び関係性を、その表現形式が変わったときにも保つようにすることである。例えば、コンテンツがスクリーンリーダーによって読み上げられたり、コンテンツ制作者が提供するスタイルシートがユーザー・スタイルシートに置き換えられたりしたときには、表現形式が変わる。
画面を見ている利用者は、様々な視覚的な手がかりによって構造を知覚する。例えば、見出しは大きめで太字のフォントで、次の段落とはスペースを空けて表示されていることがほとんどである。リスト項目は、その先頭に中黒等があって、字下げされていることが多い。段落と段落の間にはスペースがある。共通の特徴を有する条項は、表の行と列で整理されている。フォームの複数のテキストフィールドは、テキストのラベルを共有するグループとして配置されていることがある。異なる背景色を用いて、いくつかのアイテムが互いに関係のあることを示していることもある。特別な意味を持つ語句は、フォントの種類を変えたり、イタリック、下線付きにすることによって示されているなどである。
同様に、聴覚的な手がかりを用いることもある。例えば、チャイム音が新しい節の開始位置を示している。声のピッチや発話のスピードを変えて、重要な情報を強調したり、引用されたテキストを示したりしている、など。
そういった関係性が、ある利用者にとって知覚可能であれば、その関係性をすべての利用者が知覚できるようにすることが可能である。情報をすべての利用者にきちんと提供できたかどうかを判断する一つの方法は、その情報に様々な感覚モダリティで連続してアクセスしてみることである。
用語集にある用語へのリンクを a 要素(又は、使用している技術特有のリンク要素)を用いて実装して、異なるフォントで示していれば、スクリーンリーダーの利用者は、用語集にある用語のところで、たとえフォントの違いに関する情報は受け取れなかったとしても、それがリンクであることが音声読み上げを聞けば分かるだろう。あるオンラインカタログの価格表示では赤い大きなフォントを使用している。スクリーンリーダーの利用者は赤色の情報は得られないが、価格の前に通貨表示を記載することで情報を得ることができる。
ウェブコンテンツ技術の中には、ある種の情報及び関係性をプログラムで解釈する手段を提供していないものがある。そういった場合には、その情報及び関係性を説明するテキストを提供すべきである。例えば、「アスタリスク (*) のある項目はすべて必須項目です。」のように説明テキストを提供する。テキストによる説明は、例えば、その親要素又は隣接する要素内などのように、(そのページをリニアライズした際に)テキストが説明している情報の近くに置くべきである。
また、場合によっては、どんな情報をテキストで示すべきで、何を直接関連付ける必要があるのかは各自の判断に委ねるしかないこともあれば、ある情報を繰り返して提供することが最も適切なこともありえる(例えば、HTML のテーブルでは、そのテーブルの要約を、そのテーブルの前にある段落とそのテーブル自体の summary属性の両方で提供する)。しかし、できる限り、テキストによる説明を提供するのではなく、その情報をプログラムが解釈できるようにしなければならない。
注記: 色の値がプログラムが解釈可能であることは要求していない。色によって伝えられる情報は、その値を明らかにするだけでは、十分に提示することができないからである。そのため、色に特有の問題については、達成基準 1.3.1 ではなく、達成基準 1.4.1 で対処している。
達成基準 1.3.1 の具体的なメリット
この達成基準は、ユーザーエージェントが個々の利用者のニーズに応じてコンテンツに適応できるようにすることによって、様々な障害のある利用者の役に立つ。
全盲の(スクリーンリーダーを使用している)利用者が、色を用いて伝えられている情報をテキストでも得られるようになる(色を用いて情報を伝えている画像の代替テキストを含む)。
点字ピンディスプレイを使用している盲ろうの利用者は、色に依存した情報を利用できないことがある。
達成基準1.3.1 の事例
必須項目のある入力フォーム
入力フォームに、いくつかの必須項目がある。必須項目のラベルを、赤で表示している。さらに、各ラベルの最後には、アスタリスクの記号文字 (*) が付いている。フォームへの入力に関する説明文には、「すべての必須項目は赤字で示してあり、アスタリスク (*) が付いています。」と書かれていて、例が後に続いている。
必須項目を示すために色とテキストを用いている入力フォーム
入力フォームに、必須項目と任意項目の両方がある。入力フォームの先頭にある説明文には、必須項目のラベルが赤字になっていて、「必須」という代替テキストのあるアイコンも付いている。赤字とアイコンの両方が、フォームのテキストフィールドとプログラムで関連付けられているので、支援技術の利用者はどれが必須項目なのかが判断できる。
各セルの見出しをプログラムが解釈可能なバスの時刻表テーブル
バスの運行スケジュールが、1列目には縦にバス停の名前が並び、1行目には横に異なるバスが並んでいる表で示されている。各セルには、バスがそのバス停に到着する時刻が書かれている。支援技術が、各セルにある時刻がどのバスとどのバス停とに関連付けられているのかを解釈することができるように、各バス停と各バスのセルは、それぞれの対応する行又は列の見出しとして示されている。
チェックボックスのラベルをプログラムが解釈可能な入力フォーム
あるフォームでは、各チェックボックスに対するラベルが、支援技術によってプログラムが解釈可能になっている。
テキスト文書
構造をプログラムが解釈できるように、シンプルなテキスト文書は、タイトルの前に2行の空行があり、アスタリスクを使ってリスト項目を示し、その他の標準的な書式の決まりに従ってフォーマットされている。
達成基準1.3.1 の実装方法及び不適合事例 - 情報及び関係性
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされている場合にのみ、次に挙げる実装方法により、この達成基準を満たすことができる。
達成基準を満たすことのできる実装方法
使用法: そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の実装方法(又は、実装方法の組合せ)がある。
状況 A: ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合:
G115: セマンティックな要素を用いて、構造をマークアップする 、かつ、 H49: セマンティックなマークアップを用いて、強調又は特別なテキストをマークアップする (HTML)
次の実装方法を用いて、表現によって伝えられている情報及び関係性をプログラムが解釈できるようにする
達成基準 1.3.1 でさらに対応が望まれる実装方法(参考)
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能、または効果的であるとは限らない。
ページレイアウトにはテーブルよりもCSSを用いる(リンク追加予定)
ARIA1: Accessible Rich Internet Applicationを用いたプロパティによって、ラベルを説明し、プログラムが解釈可能にする (ARIA)
ARIA4: Accessible Rich Internet Applicationsを用いてフォーム中の入力が必須のフィールドを明示する (ARIA)
絶対的なラベルを持たないすべてのフォームコントロールにラベルを提供する(リンク追加予定)
達成基準 1.3.1 のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準 1.3.1 に適合していないとみなした、よくある不適合事例である。
F2: 達成基準 1.3.1 の不適合事例 - 適切なマークアップ又はテキストを用いずに、テキストの見た目の表現の変化を用いて情報を伝えている
F17: 達成基準 1.3.1 及び 達成基準 4.1.1 の不適合事例 - HTMLで1対1の関係性を示すためのDOMにおける情報が不十分である(例:同じIDを持つラベル間の関係性)
F33: 達成基準 1.3.1 及び 達成基準 1.3.2 の不適合事例 - プレーン・テキストのコンテンツで、スペースを用いて複数の段組みをしている
F34: 達成基準 1.3.1 及び 達成基準 1.3.2 の不適合事例 - プレーン・テキストのコンテンツで、スペースを用いてテーブルをフォーマットしている
F42: 達成基準 1.3.1 及び 達成基準 2.1.1 の不適合事例 - スクリプトのイベントを用いて、プログラムで解釈できない方法で、リンクをエミュレートしている
F43: 達成基準 1.3.1 の不適合事例 - コンテンツにおける関係を表さない方法で、構造を示すマークアップを用いている
F46: 達成基準 1.3.1 の不適合事例 - レイアウトテーブルで、th要素、caption要素、又は空ではないsummary属性を用いている
F62: 達成基準 1.3.1 及び 達成基準 4.1.1 の不適合事例 - XMLで特定の関係性を示すためのDOMにおける情報が不十分である
F2: 達成基準 1.3.1 の不適合事例 - 適切なマークアップ又はテキストを用いずに、テキストの見た目の表現の変化を用いて情報を伝えている
F68: 達成基準 1.3.1 及び 達成基準 4.1.2 の不適合事例 - ラベルとユーザーインタフェース・コントロールとの関連付けがプログラムで解釈可能ではない
F87: 達成基準 1.3.1 の不適合事例 - CSSの :before や :after 疑似要素及び 'content' プロパティを用いて、装飾目的ではないコンテンツを挿入している
重要な用語
- プログラムが解釈(プログラムが解釈可能)
コンテンツ制作者が提供したデータからソフトウェアが解釈できること。またそのときに、 支援技術を含む様々なユーザエージェントが、この情報を抽出して利用者に様々な感覚モダリティで提示できること。
事例 1: マークアップ言語では、一般に入手可能な支援技術が、要素および属性に直接アクセスすることにより解釈できる。
事例 2: 非マークアップ言語では、ウェブコンテンツ技術特有のデータ構造から、一般に入手可能な支援技術がサポートするアクセシビリティ API を通じて支援技術に提供される。
- 構造
- 表現
利用者が知覚できる形式でコンテンツをレンダリングすること。
- 関係性
コンテンツの異なる部分間における意味のある関係。