Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This article is referenced directly by Microsoft Accessibility Insights for Windows. Microsoft Accessibility Insights for Windows can help spotlight many accessibility issues in UI, and guide you to the relevant UI framework-specific code sample to help you resolve the issue. Learn more about Microsoft Accessibility Insights for Windows.
Problem
A button in my UI can be invoked through touch and mouse, and also programmatically invoked through the UI Automation (UIA) API, but it cannot receive keyboard focus. This means my customers can't tab to the button and then press a key to invoke it.
Suggested Fix
By default, all invokable buttons should be in the tab order, enabling a customer who only uses the keyboard to intuitively leverage the functionality associated with the button, by tabbing to the button and pressing either Enter or Space.
In some cases, a custom control which is being programmatically exposed as a button, may not be in the tab order by default. The code sample below shows markup which will allow the custom control to accept keyboard focus, and for it to be added to the tab order. By adding that markup, the control will automatically be exposed through UIA with an IsKeyboardFocusable property of true.
Note
In some specific scenarios, it may be acceptable for a button to not be in the tab order. This is only the case if there exists an alternate means to intuitively and efficiently access the full functionality associated with the button, using only the keyboard, and a customer can reasonably be aware of the existence of that keyboard action. For example, the Minimize, Restore, Maximize, and Close buttons shown on an app's title bar are not in the tab order. This is because the well-known keyboard shortcuts of Win+DownArrow, Win+UpArrow, and Alt+F4 activate the functionality associated with those buttons.
Important
The markup shown below alone does not make a control keyboard accessible. Further action may be required to have the control react as expected to the typical key presses which access the full functionality associated with the control. For example, a press of Space to select the control, or a press of Enter to invoke it.
Code Sample: Making a WPF Button keyboard focusable and inserting it into the tab order.
<!-- In XAML -->
Focusable="True" IsTabStop="True"