Keyboard access is a very significant aspect of the interaction between disabled users and the Web. The more the functionalities of your project that users can handle through the keyboard, the wider the variety of assistive technologies that can be used by disabled users.
accesskey property can be placed on HTML elements to indicate to the browser that the property in question can be activated with the keyboard. For example, assume you have the following input field on a page:
<input type='text' id='name' accesskey='n' />
By using the
accesskey attribute, you instruct the browser to enable a user set focus on that field by using an access key combination (which is unique for OS and browsers) plus the
n key. For example, if a user browses your website with Chrome on a Mac, they would type 'control' + 'option' + 'n' to set focus on the 'name' field.
Kendo UI recognizes
accesskey attributes, and automatically preserves those when creating widgets. This is especially helpful in the cases when Kendo UI creates multiple DOM elements to construct some more complex widgets such as the NumericTextBox or DatePicker.
Keyboard support in Kendo UI is about more than just mapping access keys for you. It is also about ensuring that your users can access the full capabilities of the widgets by just using the keyboard. What is more, you get this kind of support right out of the box.
In addition to the
accesskey attribute support, most Kendo UI widgets also offer a series of keyboard controls that can be used to interact with them. The specific keyboard shortcuts supported by each widget are provided in its keyboard demo and are listed below:
Generally, there are two ways to implement in-widget keyboard navigation:
- Rely on
TABto focus multiple HTML elements inside a widget.
- Rely on
TABto focus only one element in the widget, and then use various other keys for in-widget navigation and actions—for example,
Page Down, etc.
Kendo UI opts for the second approach. It uses an
aria-activedescendant attribute to determine the currently active element inside the widget and is the recommended technique for complex UI components. It allows for a better control over the keyboard navigation, easier implementation of nested textboxes change handlers, and spares the need to define accessibility attributes for all possible elements that may need them. On the other hand, you need to define WAI-ARIA attributes. From an end-user's perspective, the markup of the widget is encapsulated as if a shadow DOM is used. The drawback of this approach is that the end-user is expected to be educated on how to use the widget. However, Kendo UI considers the pros to outweigh the cons.
Other articles on the accessibility support provided by Kendo UI: