キーボードのアクセシビリティKeyboard accessibility

アプリに十分なキーボード操作機能が備わっていない場合、視覚障碍や運動障碍のあるユーザーはアプリをうまく使うことができなかったり、まったく使うことができない可能性があります。If your app does not provide good keyboard access, users who are blind or have mobility issues can have difficulty using your app or may not be able to use it at all.

UI 要素間でのキーボード ナビゲーションKeyboard navigation among UI elements

キーボードでコントロールを操作するにはフォーカスが必要です。ポインターを使わずにフォーカスを移すには、UI 設計でタブ ナビゲーションを使ってコントロールにアクセスできるようにする必要があります。To use the keyboard with a control, the control must have focus, and to receive focus (without using a pointer) the control must be accessible in a UI design via tab navigation. 既定では、コントロールのタブ オーダーは、デザイン サーフェイスに追加された順序、XAML で一覧表示された順序、またはプログラムを使ってコンテナーに追加された順序と同じになります。By default, the tab order of controls is the same as the order in which they are added to a design surface, listed in XAML, or programmatically added to a container.

ほとんどの場合、XML でのコントロールの定義に基づく既定の順序が最適な順序です。これは特に、スクリーン リーダーで読み取られるコントロールの順序と一致するためです。In most cases, the default order based on how you defined controls in XAML is the best order, especially because that is the order in which the controls are read by screen readers. ただし、既定の順序は表示順序と対応するとは限りません。However, the default order does not necessarily correspond to the visual order. 実際の表示位置は親レイアウト コンテナーと特定のプロパティに依存し、それらを子要素で設定することでレイアウトに影響することがあります。The actual display position might depend on the parent layout container and certain properties that you can set on the child elements to influence the layout. アプリのタブ オーダーが適切に設定されていることを確かめるには、この動作を自身でテストする必要があります。To be sure your app has a good tab order, test this behavior yourself. 特に、グリッド形式や表形式で表されるレイアウトを使っている場合は、ユーザーが読み進める順序とタブ オーダーが一致しない可能性があります。Especially if you have a grid metaphor or table metaphor for your layout, the order in which users might read versus the tab order could end up different. それ自体は必ずしも問題になるとは限りませんが、That's not always a problem in and of itself. 必ずタッチ可能な UI とキーボードからアクセス可能な UI の両方についてアプリの機能をテストして、どちらの方法でも UI が適切に動作することを確認してください。But just make sure to test your app's functionality both as a touchable UI and as a keyboard-accessible UI and verify that your UI makes sense either way.

タブ オーダーと表示順序は、XAML を調整することで一致させることができます。You can make the tab order match the visual order by adjusting the XAML. また、既定のタブ オーダーは、TabIndex プロパティを設定して上書きできます。たとえば、次の Grid レイアウトでは、タブ ナビゲーションで列が最初に選ばれるようにしています。Or you can override the default tab order by setting the TabIndex property, as shown in the following example of a Grid layout that uses column-first tab navigation.

XAMLXAML

<!--Custom tab order.-->
<Grid>
  <Grid.RowDefinitions>...</Grid.RowDefinitions>
  <Grid.ColumnDefinitions>...</Grid.ColumnDefinitions>

  <TextBlock Grid.Column="1" HorizontalAlignment="Center">Groom</TextBlock>
  <TextBlock Grid.Column="2" HorizontalAlignment="Center">Bride</TextBlock>

  <TextBlock Grid.Row="1">First name</TextBlock>
  <TextBox x:Name="GroomFirstName" Grid.Row="1" Grid.Column="1" TabIndex="1"/>
  <TextBox x:Name="BrideFirstName" Grid.Row="1" Grid.Column="2" TabIndex="3"/>

  <TextBlock Grid.Row="2">Last name</TextBlock>
  <TextBox x:Name="GroomLastName" Grid.Row="2" Grid.Column="1" TabIndex="2"/>
  <TextBox x:Name="BrideLastName" Grid.Row="2" Grid.Column="2" TabIndex="4"/>
</Grid>

特定のコントロールをタブ オーダーから除外することができます。You may want to exclude a control from the tab order. 基本的に、コントロールを非対話型にするだけで除外することができます (IsEnabled プロパティを false に設定するなど)。You typically do this only by making the control noninteractive, for example by setting its IsEnabled property to false. 無効になったコントロールは自動的にタブ オーダーから除外されます。A disabled control is automatically excluded from the tab order. ただし、コントロールが無効になっていなくても、タブ オーダーからコントロールを除外したい場合があります。But occasionally you might want to exclude a control from the tab order even if it is not disabled. この場合は、IsTabStop プロパティを false に設定します。In this case, you can set the IsTabStop property to false.

通常、フォーカスを設定できる要素はすべて、既定でタブ オーダーに含まれています。Any elements that can have focus are usually in the tab order by default. 例外は、RichTextBlock などの一部のテキスト表示型です。このような型では、選択中のテキストにクリップボードからアクセスできるように、フォーカスを設定することができます。ただし、静的テキスト要素がタブ オーダーの対象となることは想定されていないため、タブ オーダーには含められません。The exception to this is that certain text-display types such as RichTextBlock can have focus so that they can be accessed by the clipboard for text selection; however, they're not in the tab order because it is not expected for static text elements to be in the tab order. 通常、これらの要素は対話型ではありません (これらは呼び出すことができず、テキスト入力も必要としませんが、テキスト内の選択ポイントを見つけて調整できるテキスト コントロール パターンはサポートしています)。They're not conventionally interactive (they can't be invoked, and don't require text input, but do support the Text control pattern that supports finding and adjusting selection points in text). テキストに、フォーカスを設定すると操作が可能になるという含みを持たせないでください。Text should not have the connotation that setting focus to it will enable some action that's possible. それでも、テキスト要素は、支援技術によって検出され、スクリーン リーダーによって読み上げられますが、これはその要素を実際のタブ オーダーで見つけるのとは異なる技法に依存しています。Text elements will still be detected by assistive technologies, and read aloud in screen readers, but that relies on techniques other than finding those elements in the practical tab order.

TabIndex 値を調整する場合も、既定の順序を使う場合も、次のルールが適用されます。Whether you adjust TabIndex values or use the default order, these rules apply:

  • TabIndex が 0 の UI 要素は、XAML または子コレクションでの宣言順序に基づいてタブ オーダーに追加されます。UI elements with TabIndex equal to 0 are added to the tab order based on declaration order in XAML or child collections.
  • TabIndex が 0 を超える UI 要素は、TabIndex 値に基づいてタブ オーダーに追加されます。UI elements with TabIndex greater than 0 are added to the tab order based on the TabIndex value.
  • TabIndex が 0 未満の UI 要素はタブ オーダーに追加され、値 0 の UI 要素よりも前に表示されます。UI elements with TabIndex less than 0 are added to the tab order and appear before any zero value. これは、HTML による tabindex 属性の処理とは異なる場合があります (古い HTML 仕様では、負の値の tabindex がサポートされていませんでした)。This potentially differs from HTML's handling of its tabindex attribute (and negative tabindex was not supported in older HTML specifications).

UI 要素内でのキーボード ナビゲーションKeyboard navigation within a UI element

コンポジット要素の場合は、含まれている要素間で正しい内部ナビゲーションが実行できることが重要です。For composite elements, it is important to ensure proper inner navigation among the contained elements. コンポジット要素では、その現在のアクティブな子を管理して、すべての子要素にフォーカスを設定できるようにする場合のオーバーヘッドを減らすことができます。A composite element can manage its current active child to reduce the overhead of having all child elements able to have focus. このようなコンポジット要素もタブ オーダーに含まれ、キーボード ナビゲーション イベント自体を処理します。Such a composite element is included in the tab order, and it handles keyboard navigation events itself. 複合コントロールには、多くの場合、コントロールのイベント処理の中に既に内部ナビゲーション ロジックが組み込まれています。Many of the composite controls already have some inner navigation logic built into the into control's event handling. たとえば、項目の方向キー トラバーサルは、既定では ListView コントロール、GridView コントロール、ListBox コントロール、FlipView コントロールで有効になります。For example, arrow-key traversal of items is enabled by default on the ListView, GridView, ListBox and FlipView controls.

特定のコントロール要素に対するポインター操作やイベントの代わりにキーボードを利用Keyboard alternatives to pointer actions and events for specific control elements

クリックできる UI 要素をキーボードでも呼び出すことができるようにします。Ensure that UI elements that can be clicked can also be invoked by using the keyboard. キーボードで UI 要素を操作するには、要素にフォーカスが必要になります。To use the keyboard with a UI element, the element must have focus. フォーカスとタブ ナビゲーションをサポートするのは、Control から派生するクラスだけです。Only classes that derive from Control support focus and tab navigation.

呼び出すことができる UI 要素の場合は、Space キーと Enter キーのキーボード イベント ハンドラーを実装します。For UI elements that can be invoked, implement keyboard event handlers for the Spacebar and Enter keys. これで、基本のキーボード アクセシビリティのサポートは完全になり、ユーザーはキーボードのみを使って基本のアプリ シナリオを実行できます。つまり、ユーザーはすべての対話型の UI 要素にアクセスしたり、既定の機能をアクティブにすることができます。This makes the basic keyboard accessibility support complete and enables users to accomplish basic app scenarios by using only the keyboard; that is, users can reach all interactive UI elements and activate the default functionality.

UI で使う要素がフォーカスを取得できない場合は、独自のカスタム コントロールを作成できます。In cases where an element that you want to use in the UI cannot have focus, you could create your own custom control. IsTabStop プロパティを true に設定して入力フォーカスを有効にし、UI にフォーカス インジケーターが示される表示状態を作成して、フォーカスがある状態を視覚的に示す必要があります。You must set the IsTabStop property to true to enable focus and you must provide a visual indication of the focused state by creating a visual state that decorates the UI with a focus indicator. タブ ストップ、フォーカス、Microsoft UI オートメーションのピアとパターンのサポートを、コンテンツを合成するコントロールで処理するよう、コントロールの合成を使うと簡単になることがよくあります。However, it is often easier to use control composition so that the support for tab stops, focus, and Microsoft UI Automation peers and patterns are handled by the control within which you choose to compose your content.

たとえば、ポインター入力イベントを Image で処理するのではなく、その要素を Button でラップすると、ポインター、キーボード、フォーカスのサポートを取得できます。For example, instead of handling a pointer-pressed event on an Image, you could wrap that element in a Button to get pointer, keyboard, and focus support.

XAMLXAML

<!--Don't do this.-->
<Image Source="sample.jpg" PointerPressed="Image_PointerPressed"/>

<!--Do this instead.-->
<Button Click="Button_Click"><Image Source="sample.jpg"/></Button>

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

キーボードのナビゲーションのアクティブ化をアプリに実装するだけでなく、ショートカットをアプリの機能に実装することをお勧めします。In addition to implementing keyboard navigation and activation for your app, it is a good practice to implement shortcuts for your app's functionality. 基本的なキーボードのサポートとしてはタブ ナビゲーションで十分ですが、複雑なフォームではショートカット キーのサポートも追加すると効果的です。Tab navigation provides a good, basic level of keyboard support, but with complex forms you may want to add support for shortcut keys as well. これにより、キーボードとポインティング デバイスの両方を使うユーザーにも使いやすいアプリになります。This can make your application more efficient to use, even for people who use both a keyboard and pointing devices.

ショートカットは、ユーザーが効率的にアプリの機能にアクセスできるようにして、生産性を向上させるためのキーの組み合わせです。A shortcut is a keyboard combination that enhances productivity by providing an efficient way for the user to access app functionality. ショートカットには次の 2 つの種類があります。There are two kinds of shortcut:

  • アクセス キーは、アプリ内の個別の UI 要素へのショートカットです。An access key is a shortcut to a piece of UI in your app. アクセス キーは、Alt キーと文字キーの組み合わせで構成されます。Access keys consist of the Alt key plus a letter key.
  • ショートカット キーは、アプリ コマンドへのショートカットです。An accelerator key is a shortcut to an app command. アプリにはコマンドに正確に対応する UI がある場合とない場合があります。Your app may or may not have UI that corresponds exactly to the command. ショートカット キーは、Ctrl キーと文字キーの組み合わせで構成されます。Accelerator keys consist of the Ctrl key plus a letter key.

スクリーン リーダーやその他の支援技術を使うユーザーがアプリのショートカット キーを簡単に見つけることができることが重要です。It is imperative that you provide an easy way for users who rely on screen readers and other assistive technology to discover your app's shortcut keys. ヒント、アクセシビリティ対応の名前、アクセシビリティ対応の説明、またはその他の画面上の伝達形式を使ってショートカットが確認できるようにします。Communicate shortcut keys by using tooltips, accessible names, accessible descriptions, or some other form of on-screen communication. 少なくとも、アプリのヘルプ コンテンツにはショートカット キーについて十分な説明を用意しておく必要があります。At a minimum, shortcut keys should be well documented in your app's Help content.

スクリーン リーダーでアクセス キーを文書化するには、AutomationProperties.AccessKey 添付プロパティでショートカット キーを示す文字列を設定します。You can document access keys through screen readers by setting the AutomationProperties.AccessKey attached property to a string that describes the shortcut key. また、AutomationProperties.AcceleratorKey 添付プロパティでニーモニック以外のショートカット キーを文書化することもできます。ただし、スクリーン リーダーでは通常、どちらのプロパティも同じ方法で扱われます。There is also an AutomationProperties.AcceleratorKey attached property for documenting non-mnemonic shortcut keys, although screen readers generally treat both properties the same way. ショートカット キーの文書化は、ヒント、オートメーションのプロパティ、ヘルプ ドキュメントなど、複数の方法で行います。Try to document shortcut keys in multiple ways, using tooltips, automation properties, and written Help documentation.

次の例では、メディアを再生、一時停止、停止するボタンのショートカット キーを文書化する方法を示しています。The following example demonstrates how to document shortcut keys for media play, pause, and stop buttons.

XAMLXAML

<Grid KeyDown="Grid_KeyDown">

  <Grid.RowDefinitions>
    <RowDefinition Height="Auto" />
    <RowDefinition Height="Auto" />
  </Grid.RowDefinitions>

  <MediaElement x:Name="DemoMovie" Source="xbox.wmv"
    Width="500" Height="500" Margin="20" HorizontalAlignment="Center" />

  <StackPanel Grid.Row="1" Margin="10"
    Orientation="Horizontal" HorizontalAlignment="Center">

    <Button x:Name="PlayButton" Click="MediaButton_Click"
      ToolTipService.ToolTip="Shortcut key: Ctrl+P"
      AutomationProperties.AcceleratorKey="Control P">
      <TextBlock>Play</TextBlock>
    </Button>

    <Button x:Name="PauseButton" Click="MediaButton_Click"
      ToolTipService.ToolTip="Shortcut key: Ctrl+A"
      AutomationProperties.AcceleratorKey="Control A">
      <TextBlock>Pause</TextBlock>
    </Button>

    <Button x:Name="StopButton" Click="MediaButton_Click"
      ToolTipService.ToolTip="Shortcut key: Ctrl+S"
      AutomationProperties.AcceleratorKey="Control S">
      <TextBlock>Stop</TextBlock>
    </Button>
  </StackPanel>
</Grid>

重要

AutomationProperties.AcceleratorKey または AutomationProperties.AccessKey を設定しても、キーボード機能は有効になりません。Setting AutomationProperties.AcceleratorKey or AutomationProperties.AccessKey doesn't enable keyboard functionality. 使用する必要があるキーなどの情報を支援技術によってユーザーに渡すことができるように、そのような情報が UI オートメーション フレームワークに通知されるだけです。It only reports to the UI Automation framework what keys should be used, so that such information can be passed on to users via assistive technologies. キー処理の実装は、XAML ではなくコードで行う必要があります。The implementation for key handling still needs to be done in code, not XAML. アプリに対して実際にキーボード ショートカットの動作を実装するには、関連するコントロールに KeyDown イベントや KeyUp イベントのハンドラーをアタッチする必要があります。You will still need to attach handlers for KeyDown or KeyUp events on the relevant control in order to actually implement the keyboard shortcut behavior in your app. また、アクセス キーの下線も自動的には追加されません。Also, the underline text decoration for an access key is not provided automatically. UI で下線付きのテキストを表示する場合は、インラインの Underline 書式設定として、ニーモニックの特定のキーのテキストに明示的に下線を表示する必要があります。You must explicitly underline the text for the specific key in your mnemonic as inline Underline formatting if you wish to show underlined text in the UI.

わかりやすくするために、上の例では "Ctrl + A" などの文字列に対するリソースは使っていません。For simplicity, the preceding example omits the use of resources for strings such as "Ctrl+A". ただし、ローカライズ時にはショートカット キーについても考慮する必要があります。However, you must also consider shortcut keys during localization. ショートカット キーとして使うキーは通常、要素の表示テキスト ラベルに基づいて選ぶため、ショートカット キーをローカライズすることは適切な作業です。Localizing shortcut keys is relevant because the choice of key to use as the shortcut key typically depends on the visible text label for the element.

ショートカット キーの実装について詳しくは、Windows ユーザー エクスペリエンス インタラクション ガイドラインのショートカット キーに関する説明をご覧ください。For more guidance about implementing shortcut keys, see Shortcut keys in the Windows User Experience Interaction Guidelines.

キー イベント ハンドラーの実装Implementing a key event handler

キー イベントなどの入力イベントでは、ルーティング イベントというイベント概念を使います。Input events such as the key events use an event concept called routed events. ルーティング イベントは、共通コントロールの親が複数の子要素に対するイベントを処理できるような、合成コントロールの子要素をバブルアップすることがあります。A routed event can bubble up through the child elements of a composited control, such that a common control parent can handle events for multiple child elements. このイベント モデルは、仕様によりフォーカスの設定やタブ オーダーへの追加ができない複数の複合パートが含まれるコントロールに、ショートカット キーの操作を定義するときに役立ちます。This event model is convenient for defining shortcut key actions for a control that contains several composite parts that by design cannot have focus or be part of the tab order.

Ctrl キーなどの修飾キーのチェックを含むキー イベント ハンドラーの記述方法を示すコード例については、「キーボード操作」をご覧ください。For example code that shows how to write a key event handler that includes checking for modifiers such as the Ctrl key, see Keyboard interactions.

カスタム コントロールのキーボード ナビゲーションKeyboard navigation for custom controls

子要素間に空間的な関係が存在する場合は、子要素間を移動するためのキーボード ショートカットとして方向キーを使うことをお勧めします。We recommend the use of arrow keys as keyboard shortcuts for navigating among child elements, in cases where the child elements have a spacial relationship to each other. ツリー ビュー ノードに、展開折りたたみとノードのアクティブ化を処理するための別のサブ要素がある場合は、左右の方向キーを使って、キーボードの展開折りたたみ機能を提供します。If tree-view nodes have separate sub-elements for handling expand-collapse and node activation, use the left and right arrow keys to provide keyboard expand-collapse functionality. コントロール コンテンツ内で方向トラバーサルをサポートする指向コントロールがある場合は、適切な方向キーを使ってください。If you have an oriented control that supports directional traversal within the control content, use the appropriate arrow keys.

一般に、カスタム コントロールに対するカスタム キー処理を実装する場合は、クラス ロジックの一部として、OnKeyDown メソッドと OnKeyUp メソッドのオーバーライドを組み込みます。Generally you implement custom key handling for custom controls by including an override of OnKeyDown and OnKeyUp methods as part of the class logic.

フォーカス インジケーターの表示状態の例An example of a visual state for a focus indicator

これまで説明したように、ユーザーがフォーカスを合わせることができるカスタム コントロールには視覚的なフォーカス インジケーターが必要です。We mentioned earlier that any custom control that enables the user to focus it should have a visual focus indicator. 一般に、フォーカス インジケーターは、コントロールを囲む通常の四角形の境界線のすぐ外側に、四角形を描画するだけの簡単なものです。Usually that focus indicator is as simple as drawing a rectangle shape immediately around the control's normal bounding rectangle. 視覚的なフォーカスに使う Rectangle は、コントロール テンプレートにおけるコントロールの合成の他の部分に対するピア要素ですが、最初はコントロールにフォーカスがないため、Visibility の値には Collapsed が設定されています。The Rectangle for visual focus is a peer element to the rest of the control's composition in a control template, but is initially set with a Visibility value of Collapsed because the control isn't focused yet. コントロールがフォーカスを取得すると、表示状態が呼び出され、フォーカス表示の VisibilityVisible に設定されます。Then, when the control does get focus, a visual state is invoked that specifically sets the Visibility of the focus visual to Visible. フォーカスが別の場所に移動すると、他の表示状態が呼び出され、VisibilityCollapsed になります。Once focus is moved elsewhere, another visual state is called, and the Visibility becomes Collapsed.

既定の XAML コントロールはいずれも、フォーカスを設定できるものであれば、フォーカスを受け取ったときに視覚的なフォーカス インジケーターを適切に表示します。All of the default XAML controls will display an appropriate visual focus indicator when focused (if they can be focused). ユーザーの選択したテーマに応じて外観が異なる可能性があります (特に、ユーザーが使用してハイ コントラスト モード。)UI コントロール テンプレートを置き換えない場合に、XAML コントロールを使用する場合は、動作し、正しく表示するコントロールのビジュアル フォーカス インジケーターを取得する余分な何もする必要はありません。There are also potentially different looks depending on the user's selected theme (particularly if the user is using a high contrast mode.) If you're using the XAML controls in your UI and not replacing the control templates, you don't need to do anything extra to get visual focus indicators on controls that behave and display correctly. ただし、コントロールを再テンプレート化する必要がある場合、または XAML コントロールで視覚的なフォーカス インジケーターがどのように実現されているかを理解したい場合のために、このセクションの残りの部分では、XAML とコントロール ロジックにおけるフォーカス インジケーターの処理方法について説明します。But if you're intending to retemplate a control, or if you're curious about how XAML controls provide their visual focus indicators, the remainder of this section explains how this is done in XAML and in the control logic.

次に示す XAML の例は、Button の既定の XAML テンプレートに含まれています。Here's some example XAML that comes from the default XAML template for a Button.

XAMLXAML

<ControlTemplate TargetType="Button">
...
    <Rectangle
      x:Name="FocusVisualWhite"
      IsHitTestVisible="False"
      Stroke="{ThemeResource FocusVisualWhiteStrokeThemeBrush}"
      StrokeEndLineCap="Square"
      StrokeDashArray="1,1"
      Opacity="0"
      StrokeDashOffset="1.5"/>
    <Rectangle
      x:Name="FocusVisualBlack"
      IsHitTestVisible="False"
      Stroke="{ThemeResource FocusVisualBlackStrokeThemeBrush}"
      StrokeEndLineCap="Square"
      StrokeDashArray="1,1"
      Opacity="0"
      StrokeDashOffset="0.5"/>
...
</ControlTemplate>

ここまでのところでは、これは単なる合成です。So far this is just the composition. フォーカス インジケーターの表示を制御するには、Visibility プロパティを切り替える表示状態を定義します。To control the focus indicator's visibility, you define visual states that toggle the Visibility property. それには、VisualStateManager.VisualStateGroups 添付プロパティを使います。これは合成を定義するルート要素に適用されます。This is done using the VisualStateManager.VisualStateGroups attached property, as applied to the root element that defines the composition.

XAMLXAML

<ControlTemplate TargetType="Button">
  <Grid>
    <VisualStateManager.VisualStateGroups>
       <!--other visual state groups here-->
       <VisualStateGroup x:Name="FocusStates">
         <VisualState x:Name="Focused">
           <Storyboard>
             <DoubleAnimation
               Storyboard.TargetName="FocusVisualWhite"
               Storyboard.TargetProperty="Opacity"
               To="1" Duration="0"/>
             <DoubleAnimation
               Storyboard.TargetName="FocusVisualBlack"
               Storyboard.TargetProperty="Opacity"
               To="1" Duration="0"/>
         </VisualState>
         <VisualState x:Name="Unfocused" />
         <VisualState x:Name="PointerFocused" />
       </VisualStateGroup>
     <VisualStateManager.VisualStateGroups>
<!--composition is here-->
   </Grid>
</ControlTemplate>

指定された状態のうち 1 つのみが Visibility を直接調整し、他の状態が空のように見えることに注意してください。Note how only one of the named states adjusts Visibility directly whereas the others are seemingly empty. 表示状態の動作は、同じ VisualStateGroup の別の状態がコントロールで使われるとすぐに、前の状態で適用されていたすべてのアニメーションが取り消されるというものです。The way that visual states work is that as soon as the control uses another state from the same VisualStateGroup, any animations applied by the previous state are immediately canceled. 合成の既定の VisibilityCollapsed であるため、四角形は表示されません。Because the default Visibility from composition is Collapsed, this means the rectangle will not appear. コントロールのロジックでは、GotFocus などのフォーカス イベントをリッスンし、GoToState を使って状態を変更することで、これを制御しています。The control logic controls this by listening for focus events like GotFocus and changing the states with GoToState. 既定のコントロールを使っているか、この動作が既に設定されているコントロールを基にカスタマイズしている場合、これは既に自動的に処理されていることがほとんどです。Often this is already handled for you if you are using a default control or customizing based on a control that already has that behavior.

キーボードのアクセシビリティと Windows PhoneKeyboard accessibility and Windows Phone

Windows Phone デバイスには、通常、専用のハードウェア キーボードがありません。A Windows Phone device typically doesn't have a dedicated, hardware keyboard. ただし、ソフト入力パネル (SIP) は、複数のキーボード アクセシビリティのシナリオをサポートできます。However, a Soft Input Panel (SIP) can support several keyboard accessibility scenarios. スクリーン リーダーは、削除も含めて、テキスト SIP からのテキスト入力を読み取ることができます。Screen readers can read text input from the Text SIP, including announcing deletions. スクリーン リーダーは、ユーザーがキーをスキャンしていることを検出して、スキャンされたキー名を読み上げるため、ユーザーは指の位置を知ることができます。Users can discover where their fingers are because the screen reader can detect that the user is scanning keys, and it reads the scanned key name aloud. また、キーボード指向のアクセシビリティに関する概念の一部は、キーボードをまったく使わない関連の支援技術の動作に割り当てることもできます。Also, some of the keyboard-oriented accessibility concepts can be mapped to related assistive technology behaviors that don't use a keyboard at all. たとえば、SIP が Tab キーを含まない場合でも、ナレーターは、Tab キーを押した場合と同等のタッチ ジェスチャをサポートします。そのため、UI のコントロールを使って便利なタブ オーダーを設定することが、重要なアクセシビリティの原則であることに変わりはありません。For example, even though a SIP won't include a Tab key, Narrator supports a touch gesture that's the equivalent of pressing the Tab key, so having a useful tab order through the controls in a UI is still an important accessibility principle. 複雑なコントロール内で部品を移動するために使われる方向キーも、ナレーターのタッチ ジェスチャでサポートされます。Arrow keys as used for navigating the parts within complex controls are also supported through Narrator touch gestures. テキスト入力用ではないコントロールにフォーカスが移ると、ナレーターはそのコントロールの操作を呼び出すジェスチャをサポートします。Once focus has reached a control that's not for text input, Narrator supports a gesture that invokes that control's action.

SIP には Ctrl キーや Alt キーがないため、キーボード ショートカットは通常、Windows Phone アプリには関係ありません。Keyboard shortcuts aren't typically relevant for Windows Phone apps, because a SIP won't include Control or Alt keys.