Here at Usability Kitty, we (and by we I mean me this is a one-cat show!) pride ourselves on puns, so this week I give you several “Keys” to Better Keyboard Accessibility. These include “key” tips, as well as literal keyboard keys (the ones that clickity-clack under your fingertips). This is a continuation of a previous blog post, Focus on the Keyboard — please give this post a read first if you haven’t already!
Keyboard Keys
Now that we have a better understanding of what focus is, we can dive into a few of the most commonly used keyboard keys when navigating the web.
Key #1: Tab
We’ve already briefly discussed the tab key in my previous post on the focus state. You can use tab to move to the next focusable element on a web page.
It is worth noting here that non-focusable elements will not be affected by pressing the tab key. You will not see the focus change to a paragraph, div, span, list item, etc. unless that particular element has specific tabindex. Before I was familiar with the concept of focus and its purpose, I became frustrated when my screen reader wasn’t reading text within my div or p elements, but this was normal. Tab was not the key I was looking for!
Key #2: Shift
Tab will move you forward in the tab order, but how can you move back? Shift + tab of course!
Key #3: Enter
Semantic HTML buttons and inputs of type submit, button, reset, and file will respond to the enter key. You can also use the enter key to activate links.
Key #4: Space
The spacebar is used to toggle other input controls. This includes checking checkboxes and radio buttons. The spacebar will activate a semantic button as well.
Keyboard Keys Bonus Round: Arrow Keys
When not focused on a semantically focusable element, the up and down arrow keys can scroll the page up and down. Additionally, you can use them to move between options in a select dropdown. All four arrow keys can also move between radio button options and values in an input of type range.
“Key” Tips
Now that we’re more familiar with focus and keyboard keys, let’s discuss some quick tips.
Tip #1: Add a Skip Link
This should be one of the first elements on a page to receive focus. Skip links allows the user to bypass long lists of other focusable elements, like links in your navigation, to get straight to your primary content. You can have multiple skip links if you feel the need to provide quick navigation to other significant areas of the page, but one is often enough.
Often times skip links are positioned off-screen for screen reader users, but keep in mind that keyboard users can be sighted, too. For best results, allow your skip link to become visible somewhere near the top of your page when it receives focus.
WebAIM has a great article on skip links if you’d like to learn more.
Tip #2: Check Your Focus Indicator
Even if you can tab around on your site, your users will become completely lost without a focus indicator. Again, will display by default as either a dotted line in Firefox and Internet Explorer or a blue glow in Chrome and Safari. Feel free to add your own custom focus indicator(s), but be sure that there is some visual indicator on all of focusable elements when they receive focus.
Beware of the infamous outline: 0. This is included in most CSS resets and will remove the focus indicator entirely. If you use a CSS reset, be sure to restore your outline or provide some other visual indicator.
Tip #3: Test Your Tab Order
Normally the tab order follows the structure of the DOM (Document Object Model, or the structure of your HTML). Your tab order should be logical and follow a standard reading order. This typically means left to right and top to bottom (unless your site is in a language that reads right to left, like Arabic).
If you use absolute or relative positioning, floats, or flexbox to move elements around on the page, be sure that the tab order still makes sense with your visual presentation. If your focus jumps to an unexpected area of the page, restructure your markup so that the tab order is easier to follow.
Tip #4: Use Semantic HTML Elements
Unless you have a very good reason, avoid using elements like divs, spans, or lis for anything more than displaying text or lists. Don’t style a div to look and act like a button or a span to look and act like a link (or worse, style a button to look like a link, or vice versa). Semantic form elements and links already come with all the proper roles and functionality you need for assistive technologies.
Always consider what behavior you expect an element to perform and consider if a semantic HTML element might be suitable. Consider the following examples:
- Do you need to select multiple items in a list?
Use checkboxes. - Do you need to select one of a number of items?
Use radio buttons or a select dropdown. - Do you need to perform an action, like submitting a form or opening a modal dialog?
Use a button. - Do you need to navigate to another page or a different location the same page?
Use a link.
This isn’t to say that you can’t ever use a div as a button. ARIA roles can fill in the gaps where semantic HTML is not possible, but only use this approach as a last resort and/or when the functionality you are looking for is not available through a semantic element. Mozilla Developer Network has a good article on semantic HTML for further reading.
Summary
Keyboard support is a vital aspect of accessibility. By learning some common keystrokes and equipping yourself with a few helpful tips, you can better keep the keyboard in mind while developing for the web.