Assistive Tech to the rescue!
Next to the mouse, keyboards are one of the most commonly used input controls when navigating the web. In addition to able-bodied “power” users, many with motor disabilities or any type of muscular impairments rely on a keyboard of some form for navigation. Of the keys on a keyboard, the
spacebar and respective arrow keys—
←—are standard keystrokes used for interaction. More specifically, the
tab key is used to navigate through links and form controls, the
enter (and also
spacebar) key is used to select an element and the arrow keys are used for general navigation. Because every key is used in such a specific manner, interactions via the keyboard should be predictable. Many applications unsurprisingly fall short of this expectation. Common pitfalls include issues relating to focus management and navigation order. (If you’re interested in learning more about how keyboard users use their keyboards, check out this WebAIM article)
Where do we go from here?
When an element on the web has “focus”, it means that it can be manipulated and activated either via a keyboard or other alternative input controls. It almost goes without saying, but focus is handy for keeping track of where you are on a page. For most sighted users, this focus is noticeable visually via the default browser outline focus style (if it hasn’t already been removed) and/or by the position of the cursor. One way to tackle focus management in applications is to direct your users down a logical navigation path via focus order.
Focus order is the navigational sequence in which a keyboard user accesses elements on a page in an order that makes sense. For example, if we were to have a menu which has submenu items, only the menu needs to be focused since it can be assumed that a menu has subcategories within it. The best strategy to achieve this is to add a tabindex attribute to top-level interactive elements. The general practice for using tabindex is to set the value to 0 or -1, depending on whether or not you want an element to receive focus (0 for focus, -1 for no focus). Another strategy is to make use of “focus trapping”. Focus trapping is the concept of literally trapping focus in an element context i.e. a modal so anything outside that element cannot be directly accessed. This is of course a fairly advanced technique for focus management so use it with caution. For more on focus management, check out this Smashing article by Kushagra Gour.
Dynamic Content Updates
aria-live attribute via a politeness setting. For more on this, MDN has a pretty comprehensive doc on using it.
Client side applications are not inherently inaccessible. Their role in yielding inaccessible content is largely a result of whether or not accessibility was considered in the development process. While the techniques discussed here are by no means exhaustive, they are hopefully a good starting point to start building more accessible client side applications.