フォーカス順序:
達成基準 2.4.3 を理解する
2.4.3 フォーカス順序: ウェブページが順を追ってナビゲートできて、そのナビゲーション順が意味又は操作に影響を及ぼす場合、フォーカス可能なコンポーネントは、意味及び操作性を損なわない順序でフォーカスを受け取る。 (レベル A)
この達成基準の意図
この達成基準の意図は、利用者がコンテンツ内を一つずつ順を追いながら行き来している際に、キーボードにより操作可能な順序でコンテンツの意味に添って、情報と出会うようにすることである。このことにより、利用者のコンテンツに対するメンタルモデルを一貫したものとし、利用者が困惑する可能性を引き下げる。コンテンツの論理的な関係性を反映した異なる順序になることもある。例えば、テーブルのある行又は列にある構成要素内を一度に移動する際には、行を移動する際も列を移動する際もコンテンツにおける関係性を反映した順序になる。どちらの順序もこの達成基準を満たすことができる 。
ウェブコンテンツでのナビゲーションの順番が決まる方法は、コンテンツで用いるウェブコンテンツ技術によって定義されている。例えば、シンプルな HTML は、タブ移動順序によってナビゲーション順序を定義している。動的な HTML では、フォーカスを他の要素にも割り当てることができるように tabindex 属性を付加して、スクリプトを用いてナビゲーション順序を修正することができる。スクリプトも、tabindex 属性も使用していない場合、ナビゲーション順序は、コンポーネントがコンテンツの流れの中で表れる順序になる（HTML 4.01 仕様書の 17.11 "Giving focus to an element"：日本語訳は「17.11 ある要素にフォーカスを合わせる」を参照のこと）。
この達成基準で対処しているナビゲーション順序ではない、キーボード・ナビゲーションの一例は、ツリー・コンポーネントを行き来するための矢印キーを用いたナビゲーションである。利用者は、上下の矢印キーを使って、ツリーのノードからノードへと移動することができる。右向き矢印キーを押下するとノードを展開して、それから下向き矢印キーを押下すると新しく展開されたノードへと移動していく。アイテムが展開されたり閉じられたりするたびに、ナビゲーション順序に追加されたり削除されたりするので、このナビゲーション順序は、ツリー・コントロールで予期される順序に従っている。そして、アイテムが展開されたり閉じられたりするたびに、ナビゲーション順序に追加されたり削除されたりする。
利用者はウェブページを理解して操作できているが、フォーカス順序がプログラムが解釈する音声読み上げ順序（達成基準 1.3.2 を参照）とは一致しないかもしれない。コンテンツに対して考えられうる論理的な音声読み上げ順序が数通りあり、フォーカス順序はそのうちのどれかと合致するのかもしれない。しかし、特定のプレゼンテーションにおける順序が、プログラムが解釈する音声読み上げ順序とは異なるとき、複数あるプレゼンテーションの一つを使う利用者は、そのウェブページを理解したり操作したりするのを難しいと感じるかもしれない。コンテンツ制作者は、ウェブページを設計する際に、すべての利用者のことを注意深く考慮すべきである。
例えば、画面を見ているキーボードの利用者が、ウェブページの視覚的なプレゼンテーションの順序で情報をやりとりしているのに対し、スクリーンリーダーの利用者は、プログラムで判断される音声読み上げ順序で情報をやりとりしている。フォーカス順序が双方の利用者にとって意味が通じるようにし、どちらかがコンテンツ内をランダムに飛び回るようなことのないように、注意すべきである。
明確にするために:
フォーカス可能な構成要素は、ナビゲーションの順序が意味と操作性に影響を及ぼす時のみ、意味と操作性を保つ順序でフォーカスを受ける必要がある。
必要な場合は、意味と操作性を保つ複数の順序があるかもしれない。
意味と操作性を保つ複数の順序がある場合、それらのうち1つは提供される必要がある。
達成基準 2.4.3の具体的なメリット:
これらの達成方法は、コンテンツ内を順番に行き来していて、フォーカス順序が音声読み上げ順序と一致しているものと考えている、キーボードの利用者の役に立つ。
論理的で、使いやすいフォーカス順序は、ページの操作をキーボード使用に依存している運動障害のある利用者の役に立つ。
字を読むのが困難な障害のある利用者は、Tab キーを押下してフォーカスが予期しないどこかへ移動してしまうと、迷子のようになってしまう恐れがある。彼らは論理的なフォーカス順序の恩恵を受けている。
視覚障害のある利用者は、Tab キーを押下してフォーカスが予期しないどこかへ移動してしまったり、インタラクティブな要素に囲まれているコンテンツを容易に見つけることができなかったりすると、迷子のようになってしまう恐れがある。
画面拡大ソフトを使用していて、拡大率を高くしている利用者には、ページのごく小さい一部分だけしか見えないことがある。そのような利用者は、フォーカス順序が論理的でないと、誤った文脈でコンテンツの一部分を解釈してしまう恐れがある。
達成基準 2.4.3の事例
インタラクティブなコントロールのツリーがあるウェブページ上で、利用者は上下の矢印キーを使って、ツリーのノードからノードへと移動することができる。右向き矢印キーを押下するとノードを展開して、それから下矢印キーを押下すると新しく展開されたノードへと移動していく。
あるウェブページは、スクリプトでモードレス・ダイアログ（ダイアログボックスを閉じなくても作業が続行できるタイプのダイアログボックス）を実装している。起動ボタンを押下すると、ダイアログが開く。ダイアログ内にあるインタラクティブな要素が、起動ボタンのすぐ後のフォーカス順序の位置に挿入される。ダイアログが開いているときには、フォーカス順序は、その起動ボタンからダイアログ内の要素へ移動し、それから起動ボタンの後にあるインタラクティブな要素へと移動する。ダイアログが閉じているときは、フォーカス順序は起動ボタンからその次に続いている要素へ移動する。
あるウェブページは、スクリプトでモーダル・ダイアログ（ダイアログボックスの中だけで強制的に作業をさせるダイアログボックスで、それが閉じられない限り作業の続行ができない）を実装している。起動ボタンを押下すると、ダイアログが開き、そのダイアログにある最初のインタラクティブな要素にフォーカスがあたる。ダイアログが開いている限り、フォーカスはダイアログ内の要素だけに限定される。ダイアログが閉じられると、フォーカスはボタン又はボタンの次にある要素へ戻る。
HTML で制作されたウェブページには、左側にナビゲーションがある。そのナビゲーションは、HTML ではメインコンテンツの後にあり、CSS を用いてページの左側に表示されるように指定されている。tabindex 属性又はJavaScriptを用いずに、フォーカスがメインコンテンツへ移動できるようにするためである。
注記: この事例は達成基準を満たしているが、必ずしもすべての CSS による配置が当てはまるとはかぎらない。配置が複雑な例では、意味及び操作性を保持できることもあれば、できないこともある。
次の例は、この達成基準を満たさない：
ある企業のウェブサイトに、マーケティングデータを収集するフォームがあり、利用者がその企業の発行するいくつかのニュースレターに登録できるようになっている。マーケティングデータを収集するためのフォームのセクションには、氏名、郵便番号、県、市町村、番地などのテキストフィールドがある。フォームのその他のセクションには、利用者が配信してほしいニュースレターを指定することができるようにいくつかのチェックボックスがある。しかし、そのフォームのタブ移動順序は、フォームにおける異なるセクションのフィールドを行ったり来たりする。そのため、フォーカスは、氏名のテキストフィールドからあるチェックボックスへ、次に番地のテキストフィールドへ、そしてまた別のチェックボックスへというふうに移動してしまう。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準 2.4.3 の達成方法及び不適合事例 - フォーカス順序
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
十分な達成方法
次の達成方法の一つを用いて、コンテンツ内の順序及び関係性に従った順序でフォーカスを要素に与える：
次の達成方法の一つを用いて、ウェブページを動的に変化させる：
SCR26: 動的なコンテンツを DOM のそのトリガーとなる要素の直後に挿入する (Scripting)
SCR37: デバイス非依存な方法でカスタム・ダイアログを作成する (Scripting)
SCR27: DOM を用いて、ページ上にある複数のセクションを並び替える (Scripting)
2.4.3 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
キーボードフォーカスを受け取ったリンクもしくはコントロールが、強調され非常に目立つメカニズムを提供する（リンク追加予定）
代替となるプレゼンテーション順序を作り出す（リンク追加予定）
達成基準 2.4.3 のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準2.4.3に適合していないとみなした、よくある不適合事例である。
重要な用語
- ウェブページ (Web page)
単一の URI から HTTP で得た埋め込まれていないリソースに加え、 レンダリングに使われる、又はユーザエージェントがこのリソースと一緒にレンダリングすることを意図しているその他のあらゆるリソースを合わせたもの。
注記 1: どのような「その他のリソース」も主たるリソースと一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされるとは限らない。
注記 2: このガイドラインの適合範囲に含まれる対象となるウェブページとみなされるためには、リソースが「埋め込まれていない」リソースでなければならない。
事例 1: すべての埋め込まれている画像とメディアを含んだウェブリソース。
事例 2: Asynchronous JavaScript and XML (AJAX) を用いたウェブメールのプログラム。そのプログラム全体は http://example.com/mail に存在しているが、受信箱、アドレス帳、カレンダーがある。リンクまたはボタンがあり、それを押すと受信箱、アドレス帳やカレンダーを表示するが、ページの URI は全体を通して変わらない。
事例 3: カスタマイズ可能なポータルサイトで、利用者が様々なコンテンツモジュールのセットから表示させるコンテンツを選択できるようなもの。
事例 4: ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、 ウェブサイトの中のほんの1ページなのかもしれない。
- 順を追ってナビゲート (navigated sequentially)
キーボードインタフェースを用いて (一つの要素から次へ) フォーカスを移動するために、定義された順序でナビゲートすること。