Keyboard Accessibility
- those with motor disabilities who can't use a mouse
- users who rely on screen readers and other assistive technology, which require keyboard navigation
Keyboard interaction is driven by something called focus. In web applications, only one element on a document has focus at a time, and keypresses will activate whatever function is bound to that element. The currently focused element can be accessed programmatically through the DOM method.
Visually, an element with focus is represented by default with a glowing border around the element:
The most common way of moving focus along the page is through the tab
key. Elements will be traversed in the order they appear in the document outline - so that order must be carefully considered during development. By default, only links, buttons and form controls can receive keyboard focus.
Whenever possible, developers should bind behaviour to elements that can natively receive focus, such as using a rather than a div
. They should also adjust the source order of elements to change the tab traversal order.
There may, however, be cases where you'll want to change the default behaviour or tab order. This can be done through the tabindex
attribute. The tabindex
can be given the values:
- less than zero - to let readers know that an element should be focusable but not keyboard accessible
- 0 - to let readers know that that element should be accessible by keyboard
Transitions
The majority of transitions that happen in an Angular application will not involve a page reload. This means that developers will need to carefully manage what happens to focus in these cases.
Modals are one example of this:
In this example, we see that when the modal becomes visible, the OK
button immediately receives focus. This streamlines the experience for keyboard users or screen readers to match the experience given to mouse users or those without screen readers.