キーボード操作

キーボードを使い慣れているパワー ユーザーと、障碍やその他のアクセシビリティ要件を持っているユーザーのどちらにとっても可能な限り最適なエクスペリエンスを提供できるように、Windows アプリを最適化する方法について説明します。

さまざまなデバイスで、キーボード入力は Windows アプリの全体的な対話式操作エクスペリエンスの重要な部分を占めます。 キーボード エクスペリエンスが適切に設計されていると、ユーザーはアプリの UI を効率的に操作し、キーボードから手を離すことなくその完全な機能にアクセスできます。

一般的な操作パターンは、キーボードでもゲームパッドでも同じです

このトピックでは、PC でのキーボード入力のための Windows アプリの設計について重点的に説明します。 ただし、適切に設計されたキーボード エクスペリエンスは、Windows ナレーターなどのアクセシビリティ ツールのサポート、タッチ キーボードやスクリーン キーボード (OSK) などのソフトウェア キーボードの使用、ゲーム パッドやリモコンなどの他の入力デバイスの種類の処理にも重要です。

フォーカスの視覚効果、アクセス キー 、UI ナビゲーションなど、ここで説明するガイドラインと推奨事項の多くは、これらの他のシナリオにも適用できます。

注 テキスト入力はハードウェア キーボードとソフトウェア キーボードの両方に使用されますが、このトピックではナビゲーションと対話式操作に焦点を当てます。

組み込みのサポート

マウスと共に、キーボードは PC で最も広く使われている周辺機器であり、PC エクスペリエンスの基本的な部分です。 PC ユーザーは、システムでも個々のアプリでも、キーボード入力に対するエクスペリエンスがどこであっても同じであることを期待します。

すべての UWP コントロールには豊富なキーボード エクスペリエンスとユーザー操作の組み込みサポートが含まれているのに対し、プラットフォーム自体は、カスタム コントロールとアプリの両方に最適であると感じられるキーボード エクスペリエンスを作成するための広範な基盤を提供します。

UWP は任意のデバイスでキーボードをサポートします

基本的なエクスペリエンス

前に説明したように、ゲーム パッドやリモコンなどの入力デバイスと、ナレーターなどのアクセシビリティ ツールは、ナビゲーションとコマンド実行のためのキーボード入力エクスペリエンスの多くを共有しています。 入力の種類とツールに共通するこのエクスペリエンスは、開発者の追加作業を最小限に抑え、ユニバーサル Windows プラットフォームの "一度構築すれば、どこでも実行できる" という目標に貢献します。

必要に応じて、注意すべき主な違いを取り上げ、考慮する必要がある軽減策について説明します。

このトピックでは次のデバイスとツールについて説明します。

デバイス/ツール	説明
キーボード (ハードウェアとソフトウェア)	Windows アプリケーションは、標準的なハードウェア キーボードに加えて、タッチ (つまりソフトウェア) キーボードとスクリーン キーボードの 2 つのソフトウェア キーボードをサポートします。
ゲーム パッドとリモコン	ゲーム パッドとリモコンは、10 フィート エクスペリエンスでの基本的な入力デバイスです。 Windows でのゲーム パッドとリモコンのサポートについて詳しくは、「ゲームパッドとリモコンの操作」をご覧ください。
スクリーン リーダー (ナレーター)	ナレーターは Windows に組み込まれているスクリーン リーダーであり、独自の操作エクスペリエンスと機能を提供しますが、基本的なキーボード ナビゲーションと入力に依存します。 ナレーターについて詳しくは、ナレーターの概要に関する記事をご覧ください。

カスタム エクスペリエンスと効率的なキーボード操作

前に説明したように、さまざまなスキル、能力、期待を持ったユーザーに対してアプリケーションが十分に機能するためには、キーボードのサポートが重要です。 次のことをまず第一に考えることをお勧めします。

• キーボード ナビゲーションと操作をサポートする
  • アクションを実行できる項目がタブ ストップとして識別され (アクションを実行できない項目は識別されない)、ナビゲーション順序が論理的で予測可能であるようにします (「タブ ストップ」を参照)
  • 最も論理的な要素に初期フォーカスを設定します (「初期フォーカス」を参照)
  • "内部ナビゲーション" 用に方向キー ナビゲーションを提供します (「ナビゲーション」を参照)
• キーボード ショートカットをサポートする
  • クイック アクション用のアクセラレータ キーを提供します (「アクセラレータ」を参照)
  • アプリケーションの UI のナビゲーションのためのアクセス キーを提供します (「アクセス キー」をご覧ください)。

フォーカスの視覚効果

UWP では、すべての入力の種類とエクスペリエンスに適した単一のフォーカス視覚効果デザインがサポートされています。

フォーカスの視覚効果:

• UI 要素がキーボード、ゲーム パッド、リモコンからフォーカスを受け取ったときに表示されます
• UI 要素を囲む強調表示された境界線としてレンダリングされ、アクションを実行できることを示します
• ユーザーが迷子にならずにアプリの UI 間を移動するのに役立ちます
• アプリ用にカスタマイズできます (「視認性の高いフォーカスの視覚効果」をご覧ください)。

注 UWP のフォーカス視覚効果はナレーターのフォーカス四角形と同じではありません。

タブ位置

キーボードでコントロール (ナビゲーション要素を含む) を使うには、コントロールにフォーカスが設定されている必要があります。 キーボード フォーカスを受け取るコントロールの 1 つの方法は、アプリケーションのタブ オーダーでタブ位置として識別することで、タブ ナビゲーションを介してアクセスできるようにする方法です。

コントロールがタブ オーダーに含まれるようにするには、IsEnabled プロパティを true に設定し、IsTabStop プロパティを true に設定する必要があります。

タブ オーダーからコントロールを明示的に除外するには、IsTabStop プロパティを false に設定します。

既定では、タブ オーダーは UI 要素の作成順序を反映します。 たとえば、StackPanel に Button、Checkbox、TextBox が含まれている場合、タブ オーダーは Button、Checkbox、TextBox になります。

TabIndex プロパティを設定することによって、既定のタブ オーダーをオーバーライドできます。

タブ オーダーは論理的で予測可能である必要がある

論理的で予測可能なタブ オーダーを使ってキーボード ナビゲーション モデルが適切に設計されていると、アプリはより直感的になり、ユーザーが機能をいっそう効率的かつ効果的に探索、検出、アクセスするのに役立ちます。

すべての対話的なコントロールには (グループ内のコントロールでない限り) タブ位置があり、ラベルなどの対話的でないコントロールにはタブ位置がないようにする必要があります。

フォーカスがアプリケーション内を飛び回るようなカスタム タブ オーダーは避けます。 たとえば、フォーム内のコントロールのリストのタブ オーダーは、上から下、左から右に流れるようにする必要があります (ロケールによります)。

タブ位置のカスタマイズについて詳しくは、「キーボードのアクセシビリティ」をご覧ください。

タブ オーダーとビジュアル オーダーの調和を試みる

タブ オーダー (読み取り順序とも呼ばれます) と表示順序を調整すると、ユーザーがアプリの UI を使って移動する際の混乱を減らすことができます。

タブ オーダーとビジュアル オーダーの両方で、コマンド、コントロール、コンテンツにランクを付け、最も重要なものを最初に提示するようにします。 ただし、実際の表示位置は、親のレイアウト コンテナーと、レイアウトに影響を与える子要素の特定のプロパティに依存する場合があります。 具体的には、グリッド メタファーまたはテーブル メタファーを使うレイアウトでは、ビジュアル オーダーがタブ オーダーと大きく異なる場合があります。

注 ビジュアル オーダーは、ロケールと言語にも依存します。

初期フォーカス

初期フォーカスは、アプリケーションまたはページが最初に起動またはアクティブ化されたときにフォーカスを受け取る UI 要素を指定します。 キーボードを使っている場合、ユーザーがアプリケーションの UI の操作を開始するのはこの要素からになります。

UWP アプリの場合、初期フォーカスは、フォーカスを受け取ることができる要素で TabIndex が最も高いものに設定されます。 コンテナー コントロールの子要素は無視されます。 値が同じ場合は、ビジュアル ツリーで最初の要素がフォーカスを受け取ります。

最も論理的な要素に初期フォーカスを設定する

アプリの起動時またはページへの移動時にユーザーが実行する可能性が最も高い最初の (プライマリ) アクションの UI 要素に、初期フォーカスを設定します。 次に例をいくつか示します。

• ギャラリー内の最初の項目にフォーカスが設定される写真アプリ
• 再生ボタンにフォーカスが設定される音楽アプリ

初期フォーカスは、ネガティブ (または破滅的) な結果を招く可能性のある要素に設定しないでください。

このレベルの機能は、ユーザーが選択すべきものです。 重要な結果を持つ要素に初期フォーカスを設定すると、意図しないデータ損失やシステム アクセスが発生する可能性があります。 たとえば、メールに移動する場合は、フォーカスを削除ボタンに設定しないようにします。

タブ オーダーのオーバーライドについて詳しくは、フォーカス ナビゲーションに関する記事をご覧ください。

「ナビゲーション」

キーボード ナビゲーションは、通常、Tab キーと方向キーを使ってサポートされます。

既定では、UWP コントロールは次の基本的なキーボード動作に従います。

• Tab キーは、アクションを実行できるコントロールやアクティブなコントロールの間をタブ オーダーで移動します。
• Shift + Tab キーは、逆のタブ オーダーでコントロール間を移動します。 ユーザーが方向キーを使ってコントロール内を移動した場合、フォーカスはコントロール内の最後の既知の値に設定されます。
• 方向キーは、コントロール固有の "内部ナビゲーション" を示します。ユーザーが "内部ナビゲーション" に入った場合、方向キーはコントロールから外に移動しません。 次のような例があります。
  • 上/下方向キーを使うと、ListView および MenuFlyout 内でフォーカスが移動します。
  • Slider および RatingsControl の現在選択されている値が変更されます。
  • TextBox 内でキャレットが移動します。
  • TreeView 内の項目が展開/折りたたまれます。

アプリケーションのキーボード ナビゲーションを最適化するには、これらの既定の動作を使用します。

関連するコントロールのセットで "内部ナビゲーション" を使用する

一連の関連するコントロールに方向キーのナビゲーションを提供すると、アプリケーションの UI の全体的な組織内の関係が強化されます。

たとえば、ここに示した ContentDialog コントロールでは、横 1 列のボタンの内部ナビゲーションが既定で提供されます (カスタム コントロールについては、「コントロール グループ」セクションをご覧ください)。

関連するボタンのコレクションの操作は、方向キー ナビゲーションによって簡単になります

項目が 1 つの列に表示されている場合は、上下の方向キーで項目間を移動します。 項目が 1 つの行に表示されている場合は、左右の方向キーで項目間を移動します。 項目が複数の列になっている場合は、4 つの方向キーすべてで移動します。

関連する一連のコントロールに対して 1 つのタブ位置を定義する

関連する (または補完的な) 一連のコントロールに対して 1 つのタブ位置を定義することにより、アプリ内の全体的なタブ位置の数を最小限に抑えることができます。

たとえば、次の図は、上下に並べて表示された 2 つの ListView コントロールを示しています。 左側の図では、方向キー ナビゲーションと共にタブ ストップを使って ListView コントロール間を移動しているのに対し、右側の図では、Tab キーを使って親コントロール間を移動する必要がないようにすることで、子要素間のナビゲーションをより簡単かつ効率的にする方法が示されています。

タブ ストップを使わず、方向キーだけで移動することで、上下に並べて表示された 2 つの ListView コントロールの操作を、より簡単かつ効率的にできます。

アプリケーションの UI に最適化の例を適用する方法については、「コントロール グループ」セクションをご覧ください。

対話式操作とコマンド実行

コントロールにフォーカスが設定されたら、ユーザーは、特定のキーボード入力を使ってそれを操作し、関連する機能を呼び出すことができます。

テキスト入力

TextBox や RichEditBox のようにテキスト入力用に特に設計されたコントロールでは、すべてのキーボード入力がテキストの入力またはテキスト内の移動に使われ、他のキーボード コマンドより優先されます。 たとえば、AutoSuggestBox コントロールのドロップ ダウン メニューでは、Space キーは選択コマンドとして認識されません。

Space キー

テキスト入力モードでないときは、Space キーを押すと、フォーカスのあるコントロールに関連付けられているアクションまたはコマンドが呼び出されます (タッチによるタップやマウスによるクリックなどと同様です)。

Enter キー

Enter キーは、フォーカスのあるコントロールに応じて、さまざまな一般的なユーザー操作を実行できます。

• Button や Hyperlink などのコマンド コントロールをアクティブにします。 エンド ユーザーが混乱しないよう、ToggleButton や AppBarToggleButton などのコマンド コントロールのように見えるコントロールも、Enter キーによってアクティブになります。
• ComboBox や DatePicker などのコントロールのピッカー UI を表示します。 Enter キーは、ピッカー UI をコミットして閉じる操作も行います。
• ListView、GridView、ComboBox などのリスト コントロールをアクティブにします。
  • 項目に追加のアクション (新しいウィンドウを開く) が関連付けられていない限り、リスト項目やグリッド項目に対する Space キーと同じように、Enter キーは選択アクションを実行します。
  • 追加のアクションがコントロールに関連付けられている場合、Enter キーは追加のアクションを実行し、Space キーは選択アクションを実行します。

注Enter キーと Space キーは、常にではありませんが、多くの場合同じアクションを実行します。

Esc キー

Esc キーを使うとと、ユーザーは操作中の UI (および、その UI で進行中のアクション) を取り消すことができます。

このエクスペリエンスの例を次に示します。

• ユーザーは、値を選んで ComboBox を開き、方向キーを使ってフォーカスの選択を新しい値に移動します。 Esc キーを押すと、ComboBox は閉じ、選んだ値は元の値にリセットされます。
• ユーザーは、メールの完全な削除アクションを呼び出し、アクションの確認を求める ContentDialog が表示されます。 ユーザーは、これが意図したアクションではないと判断し、Esc キーを押してダイアログを閉じます。 Esc キーは [キャンセル] ボタンに関連付けられているので、ダイアログは閉じられ、アクションは取り消されます。 Esc キーは、操作中の UI にのみ影響し、アプリ UI を閉じたり、前に戻ったりすることはありません。

Home and End keys

Home キーと End キーを使うと、ユーザーは UI 領域の先頭または末尾までスクロールできます。

このエクスペリエンスの例を次に示します。

• ListView と GridView コントロールの場合、Home キーはフォーカスを最初の要素に移動してそれが表示されるようにスクロールするのに対し、End キーはフォーカスを最後の要素に移動してそれが表示されるようにスクロールします。
• ScrollView コントロールの場合、Home キーは領域の先頭までスクロールしますが、End キーは領域の末尾までスクロールします (フォーカスは変更されません)。

PageUp キーと PageDown キー

Page キーを使うと、ユーザーは UI 領域をインクリメント単位にスクロールできます。

たとえば、ListView と GridView コントロールでは、PageUp キーは領域を 1 "ページ" 分 (通常はビューポートの高さ) 上にスクロールし、領域の先頭にフォーカスを移動します。 または、PageDown キーは、領域を 1 ページだけ下にスクロールし、領域の末尾にフォーカスを移動します。

キーボード ショートカット

キーボード ショートカットを使用すると、アクセシビリティのサポート強化とキーボード ユーザー向けの効率向上の両方を実現することで、アプリを使いやすくできます。

アプリでキーボード ナビゲーションとアクティブ化をサポートするのに加えて、アプリケーションの機能にショートカットを指定することもお勧めします。 タブ ナビゲーションは基本レベルのキーボード サポートとして優れていますが、さらに複雑な UI ではショートカット キーのサポートを追加することもできます。

ショートカットは、ユーザーがアプリの機能に効率的にアクセスできるようにすることで生産性を向上させるためのキーの組み合わせです。 ショートカットには 2 つの種類があります。

• アクセラレータは、アプリ コマンドを呼び出すショートカットです。 アプリには、そのコマンドに対応する特定の UI が提供される場合と提供されない場合があります。 アクセラレータは、通常、Ctrl キーと文字キーの組み合わせで構成されます。
• アクセス キーは、アプリケーションで特定の UI にフォーカスを設定するショートカットです。 アクセス キーは、通常、Alt キーと文字キーの組み合わせで構成されます。

同様のタスクをサポートする一貫性のあるキーボード ショートカットをアプリケーション間で提供することにより、ショートカットを一層便利で強力なものにし、ユーザーにとって覚えやすいものにできます。

アクセラレータ

アクセラレータは、ユーザーがアプリケーションで一般的な操作をより迅速かつ効率的に実行するのに役立ちます。

アクセラレータの例:

• メール アプリの任意の場所で Ctrl キーと N キーを同時に押すと、新しいメール アイテムが起動します。
• Microsoft Edge (および多くの Microsoft Store アプリケーション) の任意の場所で Ctrl キーと E キーを同時に押すと、検索が開始されます。

アクセラレータには、次のような特性があります。

• 主に Ctrl キーとファンクション キーのシーケンスを使用します (Windows のシステム ショートカット キーも、Alt キーと英数字以外のキーの組み合わせと Windows ロゴ キーを使用します)。
• これらは、最も一般的に使われるコマンドにのみ割り当てられます。
• これらは記憶されることが想定されており、メニュー、ヒント、ヘルプにのみ記載されています。
• サポートされている場合は、アプリケーション全体で有効になります。
• 直接内容は表示されず、記憶して使用するものなので、割り当てに一貫性が必要です。

アクセス キー

UWP でのアクセス キーのサポートについて詳しくは、「アクセス キー」のページをご覧ください。

運動機能に障碍があるユーザーは、アクセス キーを使うことで、一度に 1 つのキーを押して UI 内の特定の項目のアクションを実行できます。 さらに、上級ユーザーは、アクセス キーを使って追加のショートカット キーを伝達し、すばやくアクションを実行できます。

アクセス キーには、次のような特性があります。

• Alt キーと英数字キーを使います。
• これらは主にアクセシビリティのためのものです。
• キーのヒントを使用すると、コントロールに隣接する UI に直接内容が表示されます。
• 現在のウィンドウでのみ有効でなり、対応するメニュー項目またはコントロールに移動します。
• アクセス キーは、よく使用されるコマンド (特にコミット ボタン) に、可能な限り一貫して割り当てる必要があります。
• ローカライズされています。

一般的なキーボード ショートカット

次の表に、よく使用されるキーボード ショートカットの例を示します。

アクション	キー コマンド
すべて選択する	Ctrl + A
連続的な選択	Shift + 方向キー
無視して保存	Ctrl + S
Find	Ctrl + F
印刷	Ctrl + P
コピー	Ctrl+C
切り取り	Ctrl + X
貼り付け	Ctrl+V
元に戻す	Ctrl + Z
次のタブ	Ctrl + Tab
タブを閉じる	Ctrl + F4 または Ctrl + W
セマンティック ズーム	Ctrl + + または Ctrl + -

Windows システム ショートカットの包括的な一覧については、「Windows のキーボード ショートカット」をご覧ください。 一般的なアプリケーション ショートカットについては、Microsoft アプリケーションのキーボード ショートカットに関するページをご覧ください。

高度なエクスペリエンス

このセクションでは、UWP アプリでサポートされるさらに複雑ないくつかのキーボード操作エクスペリエンスと、アプリが異なるデバイスや異なるツールで使われる場合に注意する必要がある動作について説明します。

コントロール グループ

関連する、または補完的なコントロールのセットを、"コントロール グループ" (または方向領域) 内にグループ化できます。これにより、方向キーを使った "内部ナビゲーション" が可能になります。 コントロール グループを 1 つのタブ ストップにすることも、コントロール グループ内に複数のタブ ストップを指定することもできます。

方向キー ナビゲーション

UI 領域に類似した関連するコントロールのグループがある場合、ユーザーは方向キー ナビゲーションのサポートを期待しています。

• CommandBar 内の AppBarButtons
• ListView または GridView 内の ListItems または GridItems
• ContentDialog 内の Buttons

UWP コントロールでは、方向キー ナビゲーションが既定でサポートされています。 カスタム レイアウトとコントロール グループの場合は、XYFocusKeyboardNavigation="Enabled" を使って同様の動作を提供します。

次のコントロールを使用する場合は、方向キーのナビゲーションのサポートを追加することをご検討ください。

Dialog buttons RadioButtons

AppBarButton ListItem と GridItem

タブ位置

アプリケーションの機能とレイアウトによっては、コントロール グループの最適なナビゲーション オプションが、子要素、複数のタブ位置、またはいくつかの組み合わせへの方向キー ナビゲーションが設定された 1 つのタブ位置である場合があります。

ボタンに複数のタブ ストップと方向キーを使用する

アクセシビリティ ユーザーは、よく確立されたキーボード ナビゲーション ルールに依存しており、通常、方向キーを使ってボタンのコレクション内を移動することはありません。 ただし、視覚障碍のないユーザーは、それが自然な動作であると感じる場合があります。

このような場合の既定の UWP 動作の例は、ContentDialog です。 方向キーを使ってボタン間を移動できますが、各ボタンはタブ ストップでもあります。

使い慣れた UI パターンに 1 つのタブ ストップを割り当てる

レイアウトがコントロール グループのよく知られた UI パターンに従っている場合、グループに 1 つのタブ ストップを割り当てることで、ユーザーのナビゲーション効率が向上します。

以下に例を示します。

• RadioButtons
• 1 つの ListView のように見え、そのように動作する複数の ListViews
• タイルのグリッドのような外見と動作になるように作成された UI (スタート メニュー タイルなど)

コントロール グループの動作の指定

カスタム コントロール グループの動作をサポートするには、次の API を使います (詳細については、このトピックで後ほど説明します)。

• XYFocusKeyboardNavigation を使うと、コントロール間を方向キーで移動できます
• TabFocusNavigation は、タブ ストップが複数か 1 つかを示します
• FindFirstFocusableElement と FindLastFocusableElement は、Home キーでフォーカスを最初の項目に設定し、End キーで最後の項目に設定します

次の図は、関連付けられているラジオ ボタンのコントロール グループの直感的なキーボード ナビゲーション動作を示したものです。 この場合は、コントロール グループに対して 1 つのタブ ストップ、方向キーを使ったラジオ ボタン間の内部ナビゲーション、最初のラジオ ボタンにバインドされた Home キー、最後のラジオ ボタンにバインドされた End キーをお勧めします。

キーボードとナレーター

ナレーターは、キーボード ユーザー向けに用意された UI アクセシビリティ ツールです (他の入力の種類もサポートされています)。 ただし、ナレーターの機能は UWP アプリでサポートされるキーボード操作の範囲を超えており、ナレーター用に UWP アプリを設計するときは特別な注意が必要です。 (ナレーターの基本に関するページでは、ナレーターのユーザー エクスペリエンスについて説明されています)。

UWP キーボードの動作とナレーターでサポートされる動作の間には、次のような違いがあります。

• コントロールのラベルを読むための CapsLock + 方向キーなど、標準のキーボード ナビゲーションでは公開されない UI 要素へのナビゲーションに関して追加されたキーの組み合わせ。
• 無効になっている項目へのナビゲーション。 既定では、無効になっている項目は標準のキーボード ナビゲーションでは公開されません。
• UI の細分性に基づいて、より迅速なナビゲーションを行うためのコントロールの "ビュー"。 ユーザーは、項目、文字、単語、行、段落、リンク、見出し、表、ランドマーク、候補に移動できます。 標準のキーボード ナビゲーションでは、これらのオブジェクトはフラット リストとして表示されるため、ショートカット キーを用意しないと、ナビゲーションが煩雑になる可能性があります。

ケース スタディ – AutoSuggestBox コントロール

AutoSuggestBox の検索ボタンは、ユーザーが Enter キーを押して検索クエリを送信できるため、Tab と方向キーを使う標準的なキーボード ナビゲーションではアクセスできません。 ただし、ユーザーが CapsLock + 方向キーを押すと、ナレーターからアクセスできます。

キーボードで、ユーザーが Enter キーを押して検索クエリを送信する

ナレーターで、ユーザーが Enter キーを押して検索クエリを送信する

ナレーターでは、ユーザーは Caps Lock + 右方向キーを使用してから Space キーを押して検索ボタンにアクセスすることもできる

キーボード、ゲーム パッド、リモコン

ゲーム パッドとリモコンでは、UWP キーボードの多くの動作とエクスペリエンスがサポートされています。 ただし、キーボードでは使用できるさまざまなキー オプションがないため、ゲーム パッドとリモコンには多くのキーボードの最適化がありません (リモコンはゲーム パッドよりさらに制限されています)。

ゲーム パッドとリモコンの入力に関する UWP のサポートについて詳しくは、「ゲームパッドとリモコンの操作」をご覧ください。

以下では、キーボード、ゲーム パッド、リモコンの間のキーのマッピングを示します。

[キーボード]	ゲーム パッド	リモコン
Space	A ボタン	[選択] ボタン
Enter	A ボタン	[選択] ボタン
エスケープ特殊文字	B ボタン	[戻る] ボタン
Home/End	該当なし	該当なし
PageUp/PageDown	垂直スクロール用のトリガー ボタン、水平スクロール用のバンパー ボタン	該当なし

ゲーム パッドとリモコンで使用する UWP アプリを設計する際に注意する必要がある主な違いは次のとおりです。

• ユーザーは、テキスト入力を行うには、A ボタンを押してテキスト コントロールをアクティブにする必要があります。

• フォーカス ナビゲーションはコントロール グループに限定されず、ユーザーはアプリ内のフォーカス可能な UI 要素に自由に移動できます。

  注 オーバーレイ UI 内の場合、またはフォーカス エンゲージメント (A ボタンでエンゲージまたはエンゲージ解除されるまで、フォーカスは領域に入ったり領域から出たりできません) が指定されている場合を除き、フォーカスはキー押下方向の任意のフォーカス可能 UI 要素に移動できます。 詳しくは、「方向ナビゲーション」セクションをご覧ください。

• D パッドと左スティック ボタンは、コントロール間のフォーカス移動と内部ナビゲーションに使われます。

  注 ゲーム パッドとリモコンは、方向キーが押されたのと同じビジュアル オーダー内にある項目にのみ移動します。 フォーカスを受け取ることができる要素が後にない場合、その方向のナビゲーションは無効になります。 キーボード ユーザーの場合、状況によっては、必ずしもそのような制約があるとは限りません。 詳しくは、「組み込みのキーボード最適化」セクションをご覧ください。

方向ナビゲーション

方向ナビゲーションは、UWP の FocusManager ヘルパー クラスによって管理されます。これは、押された方向キー (矢印キー、D パッド) を受け取り、対応する視覚的な方向へのフォーカスの移動を試みます。

キーボードとは異なり、アプリがマウス モードをオプトアウトした場合、ゲームパッドとリモコンを使うアプリケーション全体にわたって方向ナビゲーションが適用されます。 方向ナビゲーションの最適化について詳しくは、「ゲームパッドとリモコンの操作」をご覧ください。

注 キーボードの Tab キーを使ったナビゲーションは、方向ナビゲーションとは見なされません。 詳しくは、「タブ ストップ」セクションをご覧ください。

方向ナビゲーションがサポートされている場合 方向キー (キーボードの方向キー、ゲームパッドとリモコンの方向パッド) を使って、ユーザーはコントロール間を移動できます。

方向ナビゲーションがサポートされていない場合 ユーザーは、方向キーを使ってコントロール間を移動することはできません。 コントロール間の他の移動方法 (Tab キー) は影響を受けません。

組み込みのキーボード最適化

使われるレイアウトとコントロールによっては、UWP アプリをキーボード入力専用に最適化できます。

次の例では、1 つのタブ ストップに割り当てられているリスト項目、グリッド項目、メニュー項目のグループを示します (「タブ ストップ」セクションを参照)。 グループにフォーカスがある場合は、方向キーを使って、対応するビジュアル オーダーで内部ナビゲーションが実行されます (「ナビゲーション」セクションを参照)。

単一列の方向キー ナビゲーション

単一行の方向キー ナビゲーション

複数の列と行の方向キー ナビゲーション

同種のリスト ビュー項目とグリッド ビュー項目の折り返し

方向ナビゲーションは、リスト ビュー項目とグリッド ビュー項目の複数の行と列を移動するのに最も効率的な方法であるとは限りません。

注: 通常、メニュー項目は単一列のリストですが、場合によっては特別なフォーカス ルールが適用されることがあります (「ポップアップ UI」を参照)。

List オブジェクトと Grid オブジェクトは、複数の行と列で作成できます。 これらは、通常、行優先 (1 つの行が項目でいっぱいになったら、次の行に移ります) または列優先 (1 つの列が項目でいっぱいになったら、次の列に移ります) の順序です。 行優先または列優先のどちらの順序になるかは、スクロール方向に依存するため、項目の順序がこの方向と矛盾しないようにする必要があります。

行優先順序 (項目が左から右、上から下に入力される) では、行内の最後の項目にフォーカスがある状況で右方向キーが押されると、フォーカスは次の行の最初の項目に移動します。 これと同じ動作が逆の順序で発生します。フォーカスが行の最初の項目にあるときに左方向キーが押されると、フォーカスは前の行の最後の項目に移動します。

列優先順序 (項目が上から下、左から右に入力される) では、列内の最後の項目にフォーカスがある状況で、ユーザーが下方向キーを押すと、フォーカスは次の列の最初の項目に移動します。 これと同じ動作が逆の順序で発生します。フォーカスが列の最初の項目にあるときに上方向キーが押されると、フォーカスは前の列の最後の項目に移動します。

"行優先のキーボード ナビゲーション"

列優先キーボード ナビゲーション

ポップアップ UI

前述のように、方向ナビゲーションがアプリケーションの UI におけるコントロールの表示順序に対応するようにしてください。

一部のコントロール (コンテキスト メニュー、CommandBar オーバーフロー メニュー、AutoSuggest メニューなど) では、プライマ リコントロールと使用可能な画面領域を基準とした位置と方向 (既定では下向き) にメニュー ポップアップが表示されます。 実行時には、開始方向がさまざまな要因によって影響を受ける可能性があることにご注意ください。

これらのコントロールでは、メニューが最初に開かれたとき (ユーザーによって項目が選択されていない状態)、下方向キーは常に最初の項目にフォーカスを設定し、上方向キーは常にフォーカスをメニューの最後の項目に設定します。

最後の項目にフォーカスがある状態で下方向キーが押されると、フォーカスはメニューの最初の項目に移動します。 同様に、最初の項目にフォーカスがある状態で上方向キーが押されると、フォーカスはメニューの最後の項目に移動します。 この動作は、"循環" と呼ばれ、予期しない方向に開くことがあるポップアップ メニューを移動するのに便利です。

Note

ポップアップ以外の UI では、ユーザーが無限ループにはまったように感じる可能性があるため、循環を避ける必要があります。

同じ動作をカスタム コントロールでエミュレートすることをお勧めします。 この動作を実装する方法を示すコード サンプルは、「プログラムによるフォーカス ナビゲーション」にあります。

アプリをテストする

サポートされているすべての入力デバイスでアプリをテストし、UI 要素間を一貫性のある直感的な方法で移動できることと、予期しない要素が目的のタブ オーダーに干渉しないことを確認します。

関連記事

• キーボード イベント
• 入力デバイスの識別
• タッチ キーボードの表示への応答
• フォーカスの視覚効果のサンプル
• NavigationView コントロールのキーボード操作の詳細
• キーボードのアクセシビリティ

付録

ソフトウェア キーボード

ソフトウェア キーボードは、画面上に表示され、物理的なキーボードの代わりに使用されます。入力には、タッチ、マウス、ペン/スタイラス、またはその他のポインティング デバイスを使用します。 ゲーム デバイスでは、フォーカス表示を移動するか、ゲーム パッドやリモコンのショートカット キーを使うことで、個々のキーを選択する必要があります。

タッチ キーボード

Windows 11 のタッチ キーボード

デバイスによっては、テキスト フィールドまたは他の編集可能なテキスト コントロールがフォーカスを取得すると、またはユーザーが通知センターを使って手動で有効にすると、タッチ キーボードが表示されます。

アプリがプログラムによってテキスト入力コントロールにフォーカスを設定した場合、タッチ キーボードは呼び出されません。 これにより、ユーザーが直接開始したものではない予期しない動作が発生しなくなります。 ただし、プログラムによってテキスト以外の入力コントロールにフォーカスが移動されると、キーボードは自動的に表示されなくなります。

通常、ユーザーがフォーム内のコントロール間を移動している間、タッチ キーボードは表示されたままになります。 この動作は、フォーム内の他のコントロールの種類では異なる場合があります。

次に示すのは、キーボードを閉じない状態でのタッチ キーボードを使ったテキスト入力セッションの間にフォーカスを受け取ることができる、編集以外のコントロールの一覧です。 ユーザーはタッチ キーボードを使ってこれらのコントロールとテキスト入力の間を行き来する可能性があるため、UI を不必要に変更してユーザーが混乱しないよう、タッチ キーボードは表示されたままになります。

• チェックボックス
• コンボ ボックス
• オプション ボタン
• スクロール バー
• ツリー
• ツリー項目
• メニュー
• メニュー バー
• メニュー項目
• ツール バー
• リスト
• リスト項目

タッチ キーボードの異なるモードの例を次に示します。 最初の画像は既定のレイアウトで、2 つ目の画像は拡張レイアウトです (一部の言語では利用できません)。

既定のレイアウト モードのタッチ キーボード

拡張レイアウト モードのタッチ キーボード

キーボードの操作が適切に行われると、ユーザーはキーボードのみを使ってアプリの基本的なシナリオを実現できます。つまり、ユーザーはすべての対話型要素にアクセスして、既定の機能をアクティブにできます。 キーボード ナビゲーション、アクセシビリティのためのアクセス キー、上級ユーザー向けのアクセラレータ (またはショートカット) キーなど、多くの要因が成功の度合いに影響する可能性があります。

スクリーン キーボード

タッチ キーボードと同様、スクリーン キーボード (OSK) は、物理的なキーボードの代わりに使うことができる視覚的なソフトウェア キーボードです。入力には、タッチ、マウス、ペン/スタイラス、またはその他のポインティング デバイスを使用します (タッチ スクリーンは必須ではありません)。 OSK は、物理キーボードを持たないシステム、または運動障碍によって従来の物理入力デバイスを使用できないユーザーのために提供されます。 OSK は、ハードウェア キーボードの、すべてではないにしても大部分の機能をエミュレートします。

OSK は、[設定] > [簡単操作] の [キーボード] ページから有効にすることができます。

注 OSK の方がタッチ キーボードより優先され、OSK が表示されている場合はタッチ キーボードは表示されません。

スクリーン キーボード

Xbox One のスクリーン キーボード

詳しくは、「入力にスクリーン キーボード (OSK) を使用する」をご覧ください。