解説書 達成基準 1.3.2:意味のあるシーケンス (レベル A)
要約
- 目標
- コンテンツの順序を、より多くの人が理解できる。
- 何をすればよいか
- 意味をなすコンテンツ順序を保つように、コードを用いる
- なぜそれが重要か
- 支援技術が、利用者にコンテンツを適切な順序で提示することができる。
意図
この達成基準の意図は、コンテンツの意味を理解するのに必要な音声読み上げの順序を保ちながら、ユーザエージェントがコンテンツの代替表現を提供できるようにすることである。意味のあるコンテンツの少なくとも一つの順序がプログラムによる解釈が可能であることが重要である。この達成基準を満たしていないコンテンツは、支援技術がそのコンテンツを正しくない順序で読み上げたり、代替スタイルシート又はその他の書式変更が適用されたりしたときに、利用者を困惑あるいは混乱させてしまう恐れがある。
コンテンツの並び順を変更すると、コンテンツの意味に影響を及ぼす場合、その順序には意味がある。例えば、あるページに二つの独立した記事がある場合、それらの記事の相対的な順序がそれぞれの意味に影響を及ぼす可能性はない。そのような状況においては、それらの記事自体には意味のあるシーケンスがあるかもしれないが、それらの記事が入っているテキストコンテナには意味のあるシーケンスはないかもしれない。
ある要素のプログラムが持つ意味が、そのコンテンツに意味のあるシーケンスがあるかどうかを定義している。例えば、HTML では、テキストには常に意味のあるシーケンスがある。テーブル及び順序付きリストには意味のあるシーケンスがあるが、順序なしリストには意味のあるシーケンスがない。
コンテンツの並び順には、常に意味があるとは限らない。例えば、あるウェブページのメイン部分とナビゲーション部分の相対的な順序は、それぞれの意味には影響を及ぼさない。それらは、プログラムによる解釈が可能な音声読み上げ順序で、どちらが先にもなりえる。もう一つの例としては、雑誌の記事にはいくつかの補足記事がいくつか含まれている。記事と補足記事の順序は、それぞれの意味に影響を及ぼすことはない。このような場合においては、この達成基準を満たすことのできるウェブページには、異なる音声読み上げ順序が複数あることになる。
誤解のないように書くと:
- 特定の線形順序を提供することが要求されるのは、意味に影響を与えるときだけである。
- 複数の順序が (WCAG 2.0の定義する)「正しい」読み順となることもありえる。
- 提供する正しい読み順はひとつだけでよい。
利点
- この達成基準は、コンテンツを読み上げる支援技術に依存している利用者の役に立つ。デフォルトの表現における情報の並び順で明らかになる意味は、コンテンツを読み上げで提示したときも同じになるはずである。
事例
- 事例 1: 段組をしている文書において、コンテンツを線形化した提示は、ある段の先頭から最後へと流れていき、その後次の段の先頭へと流れていく。
- 事例 2: CSS を用いて、ナビゲーションバー、ページの本文、及び関連記事を配置している。それらの視覚的提示は、プログラムによる解釈される順序とは合致していないが、そのページの意味はその見た目の順序には依存していない。
テクニック
この節にある番号付きの各項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断するテクニック、又は複数のテクニックの組み合わせを表している。しかしながら、必ずしもこれらのテクニックを用いる必要はない。その他のテクニックについての詳細は、WCAG 達成基準のテクニックを理解するの「その他のテクニック」を参照のこと。
十分なテクニック
- ウェブページにあるすべてのコンテンツについて、G57: Ordering the content in a meaningful sequence
次のテクニックのどれか一つを用いて、コンテンツの並び順を意味のあるものにする、かつ、その並び順については、G57: Ordering the content in a meaningful sequence
- H34: Using a Unicode right-to-left mark (RLM) or left-to-right mark (LRM) to mix text direction inline
- H56: Using the dir attribute on an inline element to resolve problems with nested directional runs
- C6: Positioning content based on structural markup
- C8: Using CSS letter-spacing to control spacing within a word
- C27: Making the DOM order match the visual order
- PDF3: Ensuring correct tab and reading order in PDF documents
失敗例
以下に挙げるものは、WCAG ワーキンググループが達成基準の失敗例とみなした、よくある間違いである。
- F34: Failure of Success Criterion 1.3.1 and 1.3.2 due to using white space characters to format tables in plain text content
- F33: Failure of Success Criterion 1.3.1 and 1.3.2 due to using white space characters to create multiple columns in plain text content
- F32: Failure of Success Criterion 1.3.2 due to using white space characters to control spacing within a word
- F49: Failure of Success Criterion 1.3.2 due to using an HTML layout table that does not make sense when linearized
- F1: Failure of Success Criterion 1.3.2 due to changing the meaning of content by positioning information with CSS
重要な用語
障害のある利用者の要件を満たすために、主流のユーザエージェントが提供する機能を超えた機能を提供するような、ユーザエージェントとして動作する、又は主流のユーザエージェントと共に動作するハードウェア及び/又はソフトウェア。
注記
支援技術が提供する機能としては、代替の提示 (例: 合成音声や拡大表示したコンテンツ)、代替入力手法 (例: 音声認識)、付加的なナビゲーション又は位置確認のメカニズム、及びコンテンツ変換 (例: テーブルをよりアクセシブルにするもの) などを挙げることができる。
注記
支援技術は、API を利用、監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。
注記
主流のユーザエージェントと支援技術との区別は、絶対的なものではない。多くの主流のユーザエージェントは、障害のある個人を支援する機能を提供している。基本的な差異は、主流のユーザエージェントが障害のある人もない人も含めて、広く多様な利用者を対象にしているのに対し、支援技術は、特定の障害のある利用者という、より狭く限られた人たちを対象にしているということである。支援技術により提供される支援は、対象とする利用者に特化した、よりニーズに適したものである。主流のユーザエージェントは、プログラムオブジェクトからのウェブコンテンツの抽出、マークアップの識別可能な構造への解釈といった、重要な機能を支援技術に対して提供する場合がある。
コンテンツの意味を変更せずに、単語及び段落が提示されるシーケンス。
支援技術を含む様々なユーザエージェントが抽出でき、利用者に様々な感覚モダリティで提示できるような形のデータがコンテンツ制作者によって提供されたとき、そのデータがソフトウェアによって解釈されること。
ウェブコンテンツを取得して利用者に提示するあらゆるソフトウェア。