[ This article is for Windows Phone 8 developers. If you’re developing for Windows 10, see the latest documentation. ]
Gets the access key for the object that is associated with the automation peer.
Assembly: System.Windows (in System.Windows.dll)
This implementation does nothing more than calling GetAccessKeyCore.
An access key (sometimes referred to as a keyboard shortcut or mnemonic) is a character in the text of a menu, menu item, or label of a control such as a button that invokes the associated menu function. The difference between access keys and acceleator keys is as follows. Access keys are primarily for menu items and are generally specified as a single letter. That letter is underlined in a typical menu's visual appearance. Accelerators are usually valid whenever the control has focus, and are not limited to menu concepts or the fact that a menu is open. Note that Windows Phone does not have high-level menu API in its core API set. If a control implementation responds to keyboard events to provide key access/accelerator behavior as part of its built-in code handling, the peer for the control should specify a string that contains the keyboard access key combination. To actually handle the key combination, the control should have built-in key handling logic, which is typically implemented by overriding OnKeyDown(KeyEventArgs) or OnKeyUp(KeyEventArgs) and writing specific logic for the indicated key combination. Alternatively, usercode for a control instances could define handlers for KeyDown or KeyUp.
If a control has an access key that is reported as part of the related peer implementation, this means that the control has a singular action or a primary action that can be invoked when the user presses the indicated key or key combination on the keyboard. Specific implementations of GetAccessKeyCore in Windows Phone controls are relatively rare. Most of the existing implementations are addressing containment scenarios: making sure that a contained item can forward its own access key information to the level of the container. An example of an implementation that does this is ItemAutomationPeer.GetAccessKeyCore.
Rather than specifying accelerator keys as built-in control behaviors, it is more common for application user code to specify the accelerators that are relevant to control instances as used in a specific Windows Phone application UI. In this case, accelerator keys are specified by setting the attached property AutomationProperties.AccessKey on that control instance. This is typically done in the XAML that defines the UI.
The difference between access keys and accelerator keys is as follows. Access keys are primarily for menu items and are generally specified as a single letter. That letter is underlined in a typical menu's visual appearance. Accelerators are usually valid whenever the control has focus, and are not limited to menu concepts or the fact that a menu is open.
The browser host might not report all possible key events to the Windows Phone input system, often because the browser host might handle that key event itself.