Guidelines for touch keyboard

Applies to Windows and Windows Phone

The touch keyboard enables text entry for Windows Store apps on devices that support touch, and is invoked when a user taps on an editable input field. The touch keyboard is used for text entry only and doesn't contain command keys, such as the alt or function keys.

The keyboard can be dismissed in one of two ways:

  • When the form is submitted.
  • The Hide keyboard command is invoked, as shown here.

    The Hide keyboard command on the touch keyboard

The touch keyboard typically remains visible while the user navigates between controls in a form. This behavior can vary based on the other control types within the form.

See this feature in action as part of our App features, start to finish series:  User interaction: Touch input... and beyond.

Dos and don'ts

  • Display the touch keyboard for text input only. Note that the touch keyboard doesn't provide many of the accelerators or command keys found on a hardware keyboard, such as alt, the function keys, or the Windows Logo key.
  • Don't redefine input from the touch keyboard into commands or shortcuts.
  • Don't make users navigate the app using the touch keyboard.

Touch keyboard and a custom UI

These recommendations are only relevant if your app uses custom controls. Text input controls provided by Windows properly interact with the touch keyboard by default. If you're creating a custom UI using C#/VB/C++ and XAML, use the AutomationPeer class to access UI Automation controls. The Input: Touch keyboard sample shows how to launch the touch keyboard using custom controls in apps using XAML.

If you're using JavaScript and HTML, you'll have to access UI Automation by setting the Accessible Rich Internet Applications (ARIA) properties for your custom controls. See Mapping ARIA roles to UI Automation for more info.

  • Display the keyboard throughout the entire interaction with your form.

    Ensure that your custom controls have the proper UI Automation ControlType to ensure keyboard persistence when focus moves from a text input field while in the context of text entry. For example, if you have a menu that's opened in the middle of a text-entry scenario, and you want the keyboard to persist, the menu must have the ControlType Menu. For apps using C#/VB/C++ and XAML, see AutomationControlType enumeration. For JavaScript and HTML, set the ARIA role to the appropriate control type.

  • Ensure that users can always see the input field that they're typing into.

    The touch keyboard occludes half of the screen. Windows Store apps provide a default experience for managing UI when the touch keyboard appears, by ensuring that the input field with focus scrolls into view. When customizing your UI, handle the Showing and Hiding events exposed by the InputPane object to customize your app’s reaction to the keyboard’s appearance.

  • Don't manipulate UI Automation properties to control the touch keyboard. Other accessibility tools rely on the accuracy of UI Automation properties.

  • Implement UI Automation properties for custom controls that have text input. For the keyboard to persist contextually as focus changes to different controls, a custom control must have one of the following properties:

    • Button
    • Check box
    • Combo box
    • Radio button
    • Scroll bar
    • Tree item
    • Menu
    • Menu item

    For apps using C#/VB/C++ and XAML, see AutomationControlType enumeration. For JavaScript and HTML, set the ARIA role to the appropriate control type.

Additional usage guidance

Handling the Showing and Hiding events

Here's an example of attaching event handlers for the showing and hiding events of the touch keyboard.



<SCRIPT type=”text/javascript”>
    Windows.UI.ViewManagement.InputPane.getForCurrentView().addEventListener("showing", onInputPaneShowing);
    Windows.UI.ViewManagement.InputPane.getForCurrentView().addEventListener("hiding", onInputPaneHiding);

// Handle the showing event.
function onInputPaneShowing(e)
{
    var occludedRect = e.occludedRect;

    // For this hypothetical application, the developer decided that 400 pixels is
    // the minimum height that will work for the current layout. When the
    // app gets the InputPaneShowing message, the pane is beginning to animate in.

    if (occludedRect.Top < 400)
    {
        // In this scenario, the developer decides to remove some elements (perhaps
        // a fixed navbar) and dim the screen to give focus to the text element.
        var elementsToRemove = document.getElementsByName("extraneousElements");

        // The app developer is not using default framework animation.
        _StartElementRemovalAnimations(elementsToRemove);
        _StartScreenDimAnimation();
    } 

    // This developer doesn't want the framework’s focused element visibility
    // code/animation to override the custom logic.
    e.ensuredFocusedElementInView = true;
}

// Handle the hiding event.
function onInputPaneHiding(e)
{
    // In this case, the Input Pane is dismissing. The developer can use 
    // this message to start animations.
    if (_ExtraElementsWereRemoved())
    {
        _StartElementAdditionAnimations();
    }

    // Don't use framework scroll- or visibility-related 
    // animations that might conflict with the app's logic.
    e.ensuredFocusedElementInView = true; 
}

Related topics

For developers (HTML)
Responding to keyboard interactions
Overview of the touch keyboard
input type=text element
textarea element
Showing
Hiding
InputPane
For developers (XAML)
Responding to keyboard interactions
Overview of the touch keyboard
TextBox class
TextBlock class
Showing
Hiding
InputPane
Samples
Input: Touch keyboard text input sample
Responding to the on-screen keyboard sample
Input: Touch keyboard sample (C#/C++ only)

 

 

Show:
© 2014 Microsoft