ウィジェットの中の矢印キー：roving tabindexとaria-activedescendant

ARIA Authoring Practices Guide（APG）は、どのプラットフォームにも共通する決まりとして、TabキーとShift + Tabはコンポーネントからコンポーネントへフォーカスを移し、フォーカス可能な要素をいくつも含むコンポーネントの中では、主に矢印キーがフォーカスを移す、と説明しています。WAI-ARIAはこうしたコンポーネントを複合ウィジェットと呼び、中のフォーカスを制御することを「フォーカスの管理」と呼びます。APGは、Tabの移動順に含めるのは、複合ウィジェットの中のフォーカス可能な要素1つだけにするよう求めています。

Tabキーでウィジェットに入ったときにフォーカスが移る先は、ウィジェットの種類で決まっています（APG「コンポーネントの中のキーボード移動」）。

• 前回フォーカスがあった要素（まだなければ最初の要素）：グリッド、ツリーグリッド。
• 選択中の要素（なければ最初の要素）：ラジオグループ（チェックされたボタン）、タブ、リストボックス、ツリー。
• 最初の要素： メニューバー、ツールバー。ツールバーのパターンでは、前回フォーカスがあった要素にしてもよいとしています。

中で使うキーは、APGのパターンごとに決まっています。APGは、どのキーを使うかは作成者が決めてよいものの、一般的なOSの同じ種類の部品と同じキーにするよう強く勧めています。

パターン	矢印キー	HomeとEnd
タブ（横並び）	左右で移動し、最後から最初へ、最初から最後へ回る。上下はページのスクロールに残す	任意。最初と最後のタブへ
ツールバー（横並び）	左右で移動。端で回るかは任意	任意。最初と最後のコントロールへ
ラジオグループ	上下左右でフォーカスを移してチェックし、端で回る	パターンにはない
リストボックス	上下で移動	任意。選択肢が6つ以上なら強く推奨
ツリービュー	上下で移動。右で開くか中へ、左で閉じるか親へ	最初と最後のノードへ
グリッド	上下左右で1セルずつ	HomeとEndで行の端へ、Ctrl + HomeとCtrl + Endで最初と最後のセルへ

リストボックスとツリーでは、文字を入力すると、その文字で始まる次の項目へ移るタイプアヘッドも勧められています。各パターンを実際に試せるデモは、「マウスでしか切り替えられないタブ」「キーボードで押せないアイコンが並ぶツールバー」「キーボードでもスクリーンリーダーでも選べない星評価」（ラジオグループ）、「キーボードで開けず、階層も伝わらないツリービュー」、「キーボードでセルを移動・編集できないデータグリッド」と「キーボードで選べず、読み上げもされない座席表」（どちらもグリッド）にあります。

roving tabindexでは、Tabの移動順に含める項目を tabindex="0" にし、ウィジェットの中のほかの項目をすべて tabindex="-1" にします。-1 の項目はTabの移動順から外れますが、スクリプトからはフォーカスできます。APGの手順は次のとおりです。

1. ウィジェットを作るとき、最初の項目に tabindex="0"、ほかの項目に tabindex="-1" を付けます。
2. 矢印キーが押されたら、0 を持つ項目を tabindex="-1" にし、フォーカスを移す先の項目を tabindex="0" にします。
3. その項目で focus() を呼びます。

使う場面のツールバーを、この方法で作ると次のようになります。

<div role="toolbar" aria-label="書式">
  <button type="button" tabindex="0">元に戻す</button>
  <button type="button" tabindex="-1">やり直す</button>
  <button type="button" tabindex="-1">リンクを挿入</button>
  <button type="button" tabindex="-1">画像を挿入</button>
</div>

const toolbar = document.querySelector('[role="toolbar"]');
const tools = [...toolbar.querySelectorAll('button')];

// Tabの移動先を、このボタンだけにします。
function setStop(tool) {
  for (const t of tools) t.tabIndex = t === tool ? 0 : -1;
}

toolbar.addEventListener('keydown', (event) => {
  const i = tools.indexOf(document.activeElement);
  const to = { ArrowRight: i + 1, ArrowLeft: i - 1, Home: 0, End: tools.length - 1 }[event.key];
  if (to === undefined) return;
  event.preventDefault();
  const tool = tools[(to + tools.length) % tools.length];
  setStop(tool);
  tool.focus();
});

// クリックしたボタンにフォーカスを移すブラウザーでは、クリックでもTabの移動先を移します。
toolbar.addEventListener('focusin', (event) => {
  if (tools.includes(event.target)) setStop(event.target);
});

フォーカスが実際に移るため、ブラウザーが項目を画面内へスクロールし、フォーカスの枠も描き、:focus-visible のスタイルも効きます。APGは、このスクロールをこの方法の利点の一つに挙げています。各項目はHTML標準のキー操作も保つので、ボタンはEnterキーでもSpaceキーでも押せます。APGはさらに、クリックやタップでもキーと同じように tabindex を設定するよう求めています。そうしないと、Shift + Tabでウィジェットに戻ったとき、利用者が離れた場所とは別の項目に戻ってしまいます。

aria-activedescendant では、Tabの移動順に入るのはコンテナー（またはそれを制御する入力欄）だけで、DOMのフォーカスもそこに残ります。値はアクティブな項目のidです。WAI-ARIA 1.2の4.3節によれば、ブラウザーはDOMのフォーカスをコンテナーか、それを制御する入力欄に置いたまま、aria-activedescendant が指す要素にフォーカスがあるものとして、フォーカスのイベントと状態を支援技術に伝えます。キーのイベントはDOMのフォーカスがある要素に届くので、スクリプトもそこで処理します。

その代わり、次の3つは作成者の仕事になります。

• 強調の表示： WAI-ARIA 1.2の4.3.1節は、アクティブな項目のスタイルはユーザーエージェントではなく作成者が付けるものとし、実際のフォーカスはコンテナーにあるため :focus では付けられない、としています。
• スクロール： APGは、アクティブな項目が変わるたびに画面内へスクロールするよう求めています。WAI-ARIAも、見える位置にあるようにすべき（SHOULD）としています。
• 項目の置き場所： WAI-ARIA 1.2は、参照する項目が、フォーカスのある要素のDOM上の子孫か、その aria-owns で指定した要素であることを求めています。例外は、フォーカスのある要素が、ポップアップを aria-controls で指すcombobox、textbox、searchboxの場合で、項目はそのポップアップの中にあってもかまいません。

このプロパティを使えるのは、application、combobox、composite、group、textboxと、それを受け継ぐlistbox、grid、tree、tablist、toolbarなどのロールです。使う場面のタグ欄を、この方法で作ると次のようになります。

<label for="tags">タグ</label>
<input id="tags" type="text" role="combobox"
  aria-autocomplete="list" aria-expanded="true"
  aria-controls="tag-list" aria-activedescendant="tag-1">
<ul id="tag-list" role="listbox" aria-label="タグの候補">
  <li id="tag-0" role="option" aria-selected="false">デザイン</li>
  <li id="tag-1" role="option" aria-selected="true">デザインレビュー</li>
  <li id="tag-2" role="option" aria-selected="false">デザイン案</li>
</ul>

const input = document.getElementById('tags');
const options = [...document.querySelectorAll('#tag-list [role="option"]')];

function move(index) {
  options.forEach((option, i) => option.setAttribute('aria-selected', String(i === index)));
  input.setAttribute('aria-activedescendant', options[index].id);
  options[index].scrollIntoView({ block: 'nearest' });
}

/* フォーカスは入力欄に残るので、強調は:focusではなく状態から描きます。 */
#tag-list [aria-selected="true"] {
  outline: 2px solid currentColor;
}

APGのリストボックスのポップアップでは、選択がフォーカスに連動するので、アクティブな候補が選択中の候補にもなります。開閉、Enterキー、Escapeキー、候補の件数まで含めたスクリプトは、コンボボックスのガイドにあります。

APGは、複合ウィジェットの中のフォーカスを管理する方法として、両方を説明しています。どちらを選ぶかは、フォーカスをどこに置く必要があるかで決まります。

ウィジェット	使う方法	理由
編集できるコンボボックス（候補を出す入力欄）	aria-activedescendant	リストが開いている間も入力を続けるので、DOMのフォーカスは入力欄に残す。APGのコンボボックスのパターンも、DOMのフォーカスはコンボボックスに保つとしている
選択専用のコンボボックス（独自のドロップダウン）	aria-activedescendant。APGのコンボボックスのパターンがリストボックスのポップアップについて説明しているとおり	矢印キーでリストを移動する間も、ボタン側がフォーカスを保つ。「キーボードで開けず、読み上げられないカスタムのドロップダウン」を参照
タブ、ツールバー、ラジオグループ、ツリー、グリッド	どちらでもよい。ここで挙げたガイドはroving tabindexを使う	実際のフォーカスなら、ブラウザーのフォーカスの枠とスクロールが使え、各項目のHTML標準のキー操作も残る

次の場合は、方法が決まります。

• 項目自体が独自のキー操作を持つコントロールの場合： 座席表の各セルのボタンなどです。aria-activedescendant では、キーのイベントはコンテナーに届くため（WAI-ARIA 1.2の4.3節）、中のHTML標準のボタンがEnterキーやSpaceキーを自分で受け取ることはありません。roving tabindexなら、それぞれのキー操作が残ります。
• 必要に応じて描画する長いリスト： DOMにない項目にはフォーカスも参照もできません。どちらの方法でも、移る前にその項目を描画します。

roving tabindexではフォーカスが実際に移るので、スクリーンリーダーは、新しくフォーカスを受けた項目の名前、ロール、状態をツリーから読み、製品ごとの言い方で伝えます。aria-activedescendant では、WAI-ARIA 1.2の4.3.2節により、ブラウザーは参照先の新しい要素でアクセシビリティAPIのフォーカスのイベントを発生させます。APGも、支援技術は実際にDOMのフォーカスが移ったときと同じフォーカス変更のイベントを受け取る、としています。仕様の上では、どちらの方法でも、スクリーンリーダーに伝わる内容は同じです。

違いが出るのは対応状況です。

• EaseWebの結果： 2026年11月2日の時点で、スクリーンリーダーの対応状況には、aria-activedescendant についても、roving tabindexについても、まだ結果がありません。グリッドの中のボタンの間を矢印キーで移るテストも、結果はまだ記録されていません（各セルにボタンがあるグリッド）。
• 公開されている報告（EaseWebのテストではありません）： 2023年11月に登録されたWebKitのバグ264891は、APG自身の例で、VoiceOverとSafariの組み合わせが、編集できるコンボボックスの aria-activedescendant が指す候補を読まないと報告しています。報告者によれば、NVDAとJAWSは読んでいました。WebKitは2024年4月、同じ月に修正が取り込まれたバグ272565の重複としてこれを閉じ、確認には新しいVoiceOverが必要だと記しています。
• 読むためのモード： スクリーンリーダーは、ページを読む間、矢印キーを自分で使います。ウィジェットに矢印キーを渡すかどうかはロールとスクリーンリーダーによります。モードを切り替えるキーはスクリーンリーダーのショートカットにあります。

どちらの方法でも、フォーカスは画面に表示されている内容に合わせます。

• 強調とアクティブな項目は、常に同じ項目にします。 APGは、フォーカスの表示は常に見えていなければならず、選択中の状態はフォーカスの表示と見分けられなければならない、としています。aria-activedescendant では、ブラウザーの枠は入力欄にあるので、作成者が描く強調だけが現在位置の手がかりです。
• フォーカスを失わないようにします。 フォーカスのある項目を削除するときは、論理的に続く要素へフォーカスを移します（WAI-ARIA 1.2の4.3.1節）。そうしないと、フォーカスはbody要素へ移ってしまいます。
• 戻ってきたら同じ場所にします。 WAI-ARIAは、離れた後にまたフォーカスを受けたコンテナーでは、離れたときと同じ項目をアクティブにするよう勧めています。内容が変わった場合や、メニューバーのように最初の項目に戻ることが期待される場合は例外です。
• クリックとキーを一致させます。 クリックでも、キーと同じように tabindex か aria-activedescendant を設定します。