サイトアイコン IT & ライフハックブログ|学びと実践のためのアイデア集

WCAG 2.2「2.4.3 フォーカスの順序」とは?Level Aの要件、実装、テスト方法

monitor displaying error text

Photo by Pixabay on Pexels.com

WCAG 2.2の達成基準2.4.3「フォーカスの順序」は、キーボードなどでページ内を順番に移動するとき、意味と操作性を損なわない順序で操作対象にフォーカスが当たることを求めるLevel Aの基準です。

見た目の並びとフォーカス順序を常に一致させること自体が目的ではありません。

利用者が現在地と次の操作を理解でき、ページの機能を無理なく使える順序になっているかが判断の軸です。

「フォーカスの順序」が求めること

フォーカスとは、キーボード入力などを受け取る対象として、リンク、ボタン、入力欄などが選ばれている状態です。

フォーカス順序とは、TabキーやShift+Tabキーなどで操作対象を順番に移動したときの経路を指します。

達成基準2.4.3では、ページを順次移動でき、その順序が内容の意味や操作に影響する場合に、次の条件を満たす必要があります。

論理的な順序が複数考えられる場合は、そのうち一つが意味と操作性を保っていれば基準を満たし得ます。

たとえば、互いに独立した二つの領域では、見た目と異なる順序でも直ちに不適合とは限りません。

ただし、画面を見ながらキーボードで操作する利用者にとってフォーカスが不規則に飛んで見えるなら、理解や操作を妨げる設計です。

DOM順序、視覚上の並び、フォーカス順序の違い

確認する順序 意味 主な確認点
DOM順序 HTML上で要素が並ぶ順序 内容の関係と操作の流れが、ソース上でも理解できるか
視覚上の並び CSSを適用した画面で見える順序 フォーカスが画面内を不規則に飛んで見えないか
フォーカス順序 Tabキーなどで操作対象を移動する順序 意味と操作性を保ったまま目的の操作を完了できるか

三つの順序は関係しますが、同じものではありません。

読み上げを含む内容の順序については、関連記事のWCAG 2.2「1.3.2 意味のある順序」も参照してください。

フォーカス順序を保つ実装方法

HTMLを操作の流れに沿って並べる

リンク、入力欄、ボタンなどを利用者が操作する順序でHTMLに記述すると、ブラウザーの自然なフォーカス順序を利用できます。

<form aria-labelledby="contact-heading">
  <h2 id="contact-heading">お問い合わせ</h2>
  <label for="name">お名前</label>
  <input id="name" name="name" type="text">
  <label for="email">メールアドレス</label>
  <input id="email" name="email" type="email">
  <button type="submit">確認する</button>
</form>

この例では、お名前、メールアドレス、確認ボタンの順にHTMLが並び、操作の流れも同じ順序になります。

CSSの配置機能で見た目だけを入れ替える場合は、DOM順序と視覚上の並びが離れすぎないかを確認します。

tabindexで順序を作り直さない

tabindexは、要素がフォーカスを受け取る方法を調整する属性です。

動作 実装上の考え方
0 要素をDOM上の位置に従って順次フォーカスへ加える もともと操作できるリンクやボタンには通常不要
-1 Tabキーによる順次移動から外すが、スクリプトからはフォーカスできる フォーカスを一時的に受け取る見出しなど、目的が明確な場合に使う
正の整数 小さい値から先にフォーカスを受け取る DOM順序とは別の管理が必要になり、変更時に破綻しやすいため避ける

次のように正の値で順序を組み立てると、HTMLを追加または移動した際に番号の整合が崩れやすくなります。

<button tabindex="3">送信</button>
<button tabindex="1">戻る</button>
<button tabindex="2">確認</button>

番号を振り直すのではなく、操作の流れに沿ってHTMLを並べ、ネイティブなリンク、ボタン、入力欄のフォーカス動作を優先します。

モーダル内にフォーカスを移し、閉じたら戻す

モーダルを開いたときはフォーカスをモーダル内へ移し、開いている間は背後の操作対象へ移動させません。

モーダルを閉じた後は、原則として開く操作に使ったボタンへフォーカスを戻します。

次の例では、dialog要素を開いた後に見出しへフォーカスし、閉じ方にかかわらず起点のボタンへ戻しています。

<button id="openHelp" type="button">ヘルプを開く</button>
<dialog id="helpDialog" aria-labelledby="helpTitle">
  <h2 id="helpTitle" tabindex="-1">入力方法のヘルプ</h2>
  <p>各入力欄の説明を確認できます。</p>
  <button id="closeHelp" type="button">閉じる</button>
</dialog>
const openButton = document.getElementById('openHelp');
const closeButton = document.getElementById('closeHelp');
const dialog = document.getElementById('helpDialog');
const dialogTitle = document.getElementById('helpTitle');

openButton.addEventListener('click', () => {
  dialog.showModal();
  dialogTitle.focus();
});

closeButton.addEventListener('click', () => {
  dialog.close();
});

dialog.addEventListener('close', () => {
  openButton.focus();
});

実際の初期フォーカス位置は、モーダルの内容と操作目的に合わせて選びます。

動的コンテンツでは利用者の作業を基準にする

新しい要素を追加しただけで、無条件にfocus()を実行する必要はありません。

フォーカスを突然移すと、利用者が操作していた位置を見失うおそれがあります。

よくある失敗

失敗 利用者に起きること 改善方法
CSSで見た目だけを大きく並べ替える フォーカスが画面内を行き来して見える DOM順序を見直し、視覚上の流れとのずれを抑える
正のtabindexで順序を指定する 後から追加した要素を含め、操作順が崩れやすい HTMLの自然な順序を使う
モーダルを開いても起点にフォーカスが残る 表示中のモーダルへキーボードで到達できない 開いたら内部へ移し、閉じたら起点へ戻す
動的な更新のたびにフォーカスを移す 入力や読み進めていた位置を見失う 作業場所が変わる場合だけ、目的を決めて移動する

フォーカス順序のテスト方法

フォーカス順序が論理的かどうかは内容と操作の意味に依存するため、キーボードによる手動テストが中心になります。

  1. ページの先頭からTabキーを押し、フォーカスを受け取る要素と順序を記録する。
  2. Shift+Tabキーで逆方向にも移動し、同じ経路を戻れるか確認する。
  3. 視覚上の並び、DOM順序、操作の手順を比べ、不規則な移動や飛び越しがないか確認する。
  4. モーダル、メニュー、追加表示を開閉し、移動先と戻り先が分かるか確認する。
  5. 入力エラーや内容の更新後も、利用者が作業を続けられる位置にフォーカスがあるか確認する。
  6. フォーカス位置が画面上で見えるか確認する。

フォーカスの見え方については、フォーカスの可視化とCSS実装で詳しく解説しています。

スクリーンリーダーでも、操作対象の読み上げと周囲の文脈が一致するかを確認します。

自動テストツールは正のtabindexなど一部の問題を見つける補助になりますが、順序が内容の意味を保っているかは人が判断します。

実装時の判断基準

達成基準2.4.3への対応では、単に番号や属性を整えるのではなく、利用者が意味の通る順序で操作を完了できることを確かめます。

当社では、ウェブアクセシビリティを導入しやすくするUUU ウェブアクセシビリティを提供しています。

アクセシビリティ改善を検討している方は、サービスの詳細をご覧ください。

モバイルバージョンを終了