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