アクセスキー

Access キーは、ユーザーがポインターデバイス (タッチやマウスなど) ではなく、キーボードを介してアプリの表示 UI をすばやく操作し、操作する直感的な方法を提供することで、Windows アプリケーションの使いやすさとアクセシビリティを向上させるキーボードショートカットです。

Windows appは、キーボードベースのaccess キーと、キーヒントと呼ばれる視覚的な手掛かりを通じて関連する UI フィードバックの両方に対して、プラットフォームコントロール間で組み込みのサポートを提供します。

注

キーボードは、特定の障碍を持つユーザーにとって不可欠であり ( キーボードのアクセシビリティを参照)、アプリを操作するより効率的な方法として好むユーザーにとって重要なツールでもあります。

キーボードショートカットを使用した Windows アプリケーションでの一般的なアクションの呼び出しの詳細については、アクセラレータキーのトピックを参照してください。

独自のカスタムキーボードショートカットを作成するには、「キーボードイベント」トピックを参照してください。

概要

access キーは、Alt キーと 1 つ以上の英数字キー (mnemonic と呼ばれることもあります) を組み合わせたものであり、通常は同時ではなく順番に押されます。

キーヒントは、ユーザーが Alt キーを押したときにaccess キーをサポートするコントロールの横に表示されるバッジです。各キーヒントには、関連付けられたコントロールをアクティブにする英数字キーが含まれています。

注

キーボードショートカットは、1文字の英数字で構成されるアクセスキーに対して自動的にサポートされます。たとえば、Word で Alt キーを押しながら F キーを同時に押すと、キーヒントを表示せずに [ファイル] メニューが開きます。

Alt キーを押すと、アクセスキー機能が初期化され、現在利用可能なすべてのキーの組み合わせがキーヒントとして表示されます。後続のキーストロークは、アクセスキーフレームワークによって処理されます。有効なアクセスキーが押されるか、Enterキー、Escキー、Tabキー、または方向キーが押されてアクセスキーが無効化され、キーストロークの処理がアプリに戻されるまで、無効なキーは拒否されます。

Microsoft Office アプリでは、access キーの広範なサポートが提供されます。次の図は、access キーがアクティブになっている Word の [ホーム] タブを示しています (数字と複数のキーストロークの両方のサポートに注意してください)。

Microsoft Word のアクセスキー用のキーヒントバッジ

Microsoft Word のアクセスキー用キーヒントバッジ

access キーをコントロールに追加するには、AccessKey プロパティを使用します。このプロパティの値は、アクセスキーシーケンス、ショートカット（単一の英数字の場合）、およびキーヒントを指定します。

<Button Content="Accept" AccessKey="A" Click="AcceptButtonClick" />

アクセスキーを使用するタイミング

UI で適切な場所にaccessキーを指定し、すべてのカスタムコントロールでaccess キーをサポートすることをお勧めします。

Access キーを使用すると>一度に 1 つのキーのみを押したり、マウスを使用するのが困難なユーザーを含め、運動障碍のあるユーザーのアプリのアクセシビリティが高くなります
適切に設計されたキーボード UI は、ソフトウェアアクセシビリティの重要な側面です。視覚障碍のあるユーザーや、特定の運動障碍を持つユーザーがアプリをナビゲートし、その機能と対話できるようにします。このようなユーザーはマウスを操作できず、代わりにキーボード拡張ツール、スクリーンキーボード、スクリーン拡大、スクリーンリーダー、音声入力ユーティリティなどのさまざまな支援技術に依存している可能性があります。これらのユーザーにとって、包括的なコマンドカバレッジが重要です。
Access キーを使用すると、キーボードを介して操作することを好むパワーユーザーにとってアプリがより使いやすくなっています。

経験豊富なユーザーは、キーボードベースのコマンドをより迅速に入力でき、キーボードから手を取り除く必要がないため、キーボードの使用を強く好むことがよくあります。これらのユーザーにとって、効率性と一貫性は非常に重要です。包括性は、最も頻繁に使用されるコマンドに対してのみ重要になります。

アクセスキーのスコープを設定する

access キーをサポートする要素が画面上に多数ある場合は、access キーのスコープを設定して、認知負荷を減らすことをお勧めします。これにより、画面上のaccess キーの数が最小限に抑えられます。これにより、キーの検索が容易になり、効率と生産性が向上します。

たとえば、Microsoft Wordには、リボンタブのプライマリスコープと、選択したタブのコマンドのセカンダリスコープという 2 つのaccessキースコープが用意されています。

次の図は、Word の 2 つのアクセスキースコープを示しています。 1 つ目には、ユーザーがタブやその他の最上位レベルのコマンドを選択できるプライマリ access キーが表示され、2 番目のキーには [ホーム] タブのセカンダリ access キーが表示されます。

Microsoft Word での主なアクセスキー

Microsoft Word のセカンダリーアクセスキー

Accessキーは、異なるスコープ内の要素に対して複製できます。前の例では、"2" はプライマリスコープのUndoのアクセスキーであり、セカンダリスコープでは「斜体」のアクセスキーです。

ここでは、access キースコープを定義する方法を示します。

<CommandBar x:Name="MainCommandBar" AccessKey="M" >
    <AppBarButton AccessKey="G" Icon="Globe" Label="Go"/>
    <AppBarButton AccessKey="S" Icon="Stop" Label="Stop"/>
    <AppBarSeparator/>
    <AppBarButton AccessKey="R" Icon="Refresh" Label="Refresh" IsAccessKeyScope="True">
        <AppBarButton.Flyout>
            <MenuFlyout>
                <MenuFlyoutItem AccessKey="A" Icon="Globe" Text="Refresh A" />
                <MenuFlyoutItem AccessKey="B" Icon="Globe" Text="Refresh B" />
                <MenuFlyoutItem AccessKey="C" Icon="Globe" Text="Refresh C" />
                <MenuFlyoutItem AccessKey="D" Icon="Globe" Text="Refresh D" />
            </MenuFlyout>
        </AppBarButton.Flyout>
    </AppBarButton>
    <AppBarButton AccessKey="B" Icon="Back" Label="Back"/>
    <AppBarButton AccessKey="F" Icon="Forward" Label="Forward"/>
    <AppBarSeparator/>
    <AppBarToggleButton AccessKey="T" Icon="Favorite" Label="Favorite"/>
    <CommandBar.SecondaryCommands>
        <AppBarToggleButton Icon="Like" AccessKey="L" Label="Like"/>
        <AppBarButton Icon="Setting" AccessKey="S" Label="Settings" />
    </CommandBar.SecondaryCommands>
</CommandBar>

CommandBar のプライマリーアクセスキー

CommandBar のプライマリスコープとサポートされているアクセスキー

コマンドバーのセカンダリアクセスキー

CommandBar 副次的スコープとサポートされているアクセスキー

アクセスキーの競合を回避する

Accessキーの競合は、同じスコープ内の複数の要素に重複するaccessキーがある場合、または同じ英数字で始まる場合に発生します。

システムは、ビジュアルツリーに追加された最初の要素のaccess キーを処理して、重複するaccess キーを解決します。その他はすべて無視されます。

複数のaccess キーが同じ文字 ("A"、"A1"、"AB" など) で始まる場合、システムはキー access 1 文字を処理し、それ以外のキーはすべて無視します。

一意のアクセスキーを使用するか、コマンドの範囲を指定することで、競合を回避します。

アクセスキーを選択する

accessキーを選択するときは、次の点を考慮してください。

1 文字を使用してキーストロークを最小限に抑え、アクセラレータキーを既定でサポートする (Alt + AccessKey)
2 文字を超える文字を使用しないようにする
アクセスキーの競合を回避する
文字 "I" や数字 "1" や文字 "O" や数字 "0" など、他の文字との区別が難しい文字は避けてください。
他の一般的なアプリ、例えば Word のように、よく知られた先例を利用する（"F" は "ファイル" 用、"H" は "ホーム" 用など）
コマンド名の最初の文字、または呼び戻しに役立つコマンドと密接に関連付ける文字を使用します
- 最初の文字が既に割り当てられている場合は、コマンド名の最初の文字にできるだけ近い文字を使用します (挿入の場合は "N"
- コマンド名から固有の子音を使用する (View の場合は "W" )
- コマンド名の母音を使用します。

アクセスキーを現地化する

アプリを複数の言語でローカライズする場合は、access キーのローカライズ>も行う必要があります。たとえば、en-US の "Home" の場合は "H"、es-ESでは "Incio" の場合は "I" です。

次に示すように、マークアップで x:Uid 拡張機能を使用して、ローカライズされたリソースを適用します。

<Button Content="Home" AccessKey="H" x:Uid="HomeButton" />

各言語のリソースは、projectの対応する文字列フォルダーに追加されます。

英語とスペイン語のリソース文字列フォルダー

ローカライズされたaccess キーは、プロジェクト resources.resw ファイルで指定されます。

resources.resw ファイルで指定された AccessKey プロパティを指定します

詳細については、「UI リソースの翻訳」を参照してください。

キーヒントの配置

キーヒントは、他の UI 要素、他のキーヒント、および画面の端の存在を考慮して、対応する UI 要素を基準にしてフローティングバッジとして表示されます。

通常、既定のキーヒントの場所で十分であり、アダプティブ UI の組み込みサポートを提供します。

キーヒントの自動配置の例

ただし、キーヒントの配置をより詳細に制御する必要がある場合は、次のことをお勧めします。

明らかな関連付けの原則: ユーザーは、コントロールをキーヒントに簡単に関連付けることができます。

a. キーヒントは、アクセスキー (所有者) を持つ要素の近くに配置する必要があります。
b。キーヒントは、アクセスキーを持つ有効な要素をカバーしないよう避ける必要があります。
c. キーヒントを所有者の近くに配置できない場合は、所有者と重複する必要があります。
検出可能性: ユーザーはキーヒントを使用してコントロールをすばやく検出できます。

a. キーヒントが他のキーヒントと重複することはありません。
簡単なスキャン: ユーザーはキーヒントを簡単にスキミングできます。

a. キーヒントは、互いに配置し、UI 要素と一緒に配置する必要があります。 b。キーヒントはできるだけグループ化する必要があります。

相対位置

KeyTipPlacementMode プロパティを使用して、要素ごとまたはグループごとにキーヒントの配置をカスタマイズします。

配置モードは、上、下、右、左、非表示、中央、自動です。

キーヒント配置モードの相対位置を示すスクリーンショット

キーヒントの配置モード

コントロールの中心線は、キーヒントの垂直方向と水平方向の配置を計算するために使用されます。

次の例では、StackPanel コンテナーの KeyTipPlacementMode プロパティを使用して、コントロールのグループのキーヒントの配置を設定する方法を示します。

<StackPanel Background="{ThemeResource ApplicationPageBackgroundThemeBrush}" KeyTipPlacementMode="Top">
  <Button Content="File" AccessKey="F" />
  <Button Content="Home" AccessKey="H" />
  <Button Content="Insert" AccessKey="N" />
</StackPanel>

オフセット

キーヒントの場所をさらに細かく制御するには、要素の KeyTipHorizontalOffset プロパティと KeyTipVerticalOffset プロパティを使用します。

注

KeyTipPlacementMode が Auto に設定されている場合、オフセットを設定できません。

KeyTipHorizontalOffset プロパティは、キーヒントを左または右に移動する距離を示します。

ボタンの垂直方向と水平方向のキーヒントのオフセットのスクリーンショット

ボタンの垂直方向と水平方向のキーヒントのオフセットを設定する

<Button
  Content="File"
  AccessKey="F"
  KeyTipPlacementMode="Bottom"
  KeyTipHorizontalOffset="20"
  KeyTipVerticalOffset="-8" />

画面の端の配置 {#screen-edge-alignment.ListParagraph}

キーヒントの場所は、キーヒントが完全に表示されるように、画面の端に基づいて自動的に調整されます。この場合、コントロールとキーヒントの配置ポイントの間の距離は、水平方向と垂直方向のオフセットに指定された値と異なる場合があります。

キーヒントの画面端揃えのスクリーンショット

キーヒントは、画面の端に基づいて自動的に配置されます

キーヒントのスタイル

ハイコントラストを含むプラットフォームテーマには、組み込みのキーヒントサポートを使用することをお勧めします。

独自のキーヒントスタイルを指定する必要がある場合は、KeyTipFontSize (フォントサイズ)、KeyTipFontFamily (フォントファミリ)、KeyTipBackground (背景)、KeyTipForeground (フォアグラウンド)、KeyTipPadding (パディング)、KeyTipBorderBrush(境界線の色)、KeyTipBorderThemeThickness (境界線の太さ) などのアプリケーションリソースを使用します。

フォント、順序、色などのキーヒントのカスタマイズオプションのスクリーンショット

キーヒントのカスタマイズオプション

この例では、これらのアプリケーションリソースを変更する方法を示します。

<Application.Resources>
 <SolidColorBrush Color="DarkGray" x:Key="MyBackgroundColor" />
 <SolidColorBrush Color="White" x:Key="MyForegroundColor" />
 <SolidColorBrush Color="Black" x:Key="MyBorderColor" />
 <StaticResource x:Key="KeyTipBackground" ResourceKey="MyBackgroundColor" />
 <StaticResource x:Key="KeyTipForeground" ResourceKey="MyForegroundColor" />
 <StaticResource x:Key="KeyTipBorderBrush" ResourceKey="MyBorderColor"/>
 <FontFamily x:Key="KeyTipFontFamily">Consolas</FontFamily>
 <x:Double x:Key="KeyTipContentThemeFontSize">18</x:Double>
 <Thickness x:Key="KeyTipBorderThemeThickness">2</Thickness>
 <Thickness x:Key="KeyTipThemePadding">4,4,4,4</Thickness>
</Application.Resources>

アクセスキーとナレーター

XAML フレームワークは、UI Automationクライアントがユーザーインターフェイス内の要素に関する情報を検出できるようにするオートメーションプロパティを公開します。

UIElement コントロールまたは TextElement コントロールで AccessKey プロパティを指定した場合は、 AutomationProperties.AccessKey プロパティを使用してこの値を取得できます。ナレーターなどのアクセシビリティクライアントは、要素がフォーカスを取得するたびに、このプロパティの値を読み取ります。

キーボード操作のインタラクション
キーボードアクセラレータ

サンプル

WinUI 3 ギャラリー

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-03-05