The most important goal of keyboard accessibility is to make every interactive element, such as links and form controls, available with the Tab key. This is how keyboard-only users navigate through a web page. Testing your website for keyboard accessibility is actually pretty easy: just press the Tab key and navigate from the top of the page to the bottom, highlighting active elements as you go.
Observe how easy or difficult it is to get to the main content, click a menu item, fill in a form, operate a slider, or follow your current position on the page. You can also test the reverse direction using the Shift + Tab keyboard shortcut.
2. Create Noticeable :focus Styles
CSS has a :focus pseudo-class that is triggered when a user clicks or taps on an item, or selects it with the Tab key. The :focus state only applies to focusable elements, namely <a>, <button>, <input>, <textarea>, <select>, and <area>.
Every browser comes with its own default :focus styles–usually a dotted black outline around the element, or a blurred glow, however many designers find it not to their taste and will completely remove it. This is actually the number one mistake that ruins keyboard accessibility on web pages. If you don’t like the default styles, use something that matches your website’s design.
Choose a style that’s easily noticeable but doesn’t rely solely on colors. Here’s a possible example that can work well for keyboard-only users:
1 2 3 | :focus { outline: 3px solid red; } |
3. Use Non-Color Designators for Links
Hyperlinks shouldn’t be distinguished only by color. This principle is usually mentioned in relation to visual accessibility, as people with low vision find the differences between certain colors difficult to discern. However, clearly visible links are also important for keyboard accessibility. Keyboard-only users should be able to spot links as quickly as possible. This helps them scan the page and figure out how to navigate to the part they are interested in.
Similarly to :focus styles, hyperlinks also come with default browser styling— blue underlines in most cases. However, designers frequently remove the underline and only use colors to indicate the presence of a link. If you remove the default underline always use another non-color designator that matches your website design, such as borders, icons, or outlines.
You can use the title attribute to describe a link’s content, but it only becomes visible when someone hovers the link. Keyboard-only users don’t have access to hover events, so never place crucial information in the title attribute. It also doesn’t count as a non-color designator. For example, never do this:
1 2 3 | <a href="#" title="Important information"> Click here</a> |
Instead, do this:
1 2 3 | <a href="#" title="Repetition of Important Information or addition of some secondary details"> Important information</a> |
WCAG 2.0 also warns about the accessibility problems of the title attribute. Either use it with care or don’t use it at all.
4. Use Native Control Elements
Forms are interactive elements, so they need to be accessible via the keyboard. Keyboard-only users should be able to fill in forms, press buttons, use range sliders, select options, and operate controls with ease. If you have any forms on your website you should test them one by one, using the Tab key. Think of signup forms, newsletter forms, login forms, comment forms, shopping carts, and so on.
The best way to create accessible forms is by using native control elements wherever it’s possible. Native control elements come with built-in keyboard accessibility, meaning they are focusable and respond to keypress events by default. They are as follows:
<button><input><textarea><select><option>
For example, you can create a keyboard accessible range slider with the following HTML:
1 | <input type="range" min="0" max="10"> |
Keyboard users can first focus it with the Tab key, then move the slider up and down with Space.
If you need to use a non-focusable HTML tag for an interactive element for some reason, you can make it focusable with the tabindex="0" attribute. For instance, here’s a <div> turned into a focusable button:
1 2 3 | <div role="button" tabindex="0"> Click me</div> |
The role="button" attribute in the above snippet is an ARIA landmark role. Although keyboard-only users don’t need it, it’s indispensable for screen reader users and visual accessibility.
Even if the non-native button has been made focusable, it’s still inferior to its native counterpart in terms of keyboard accessibility. You’ll understand this immediately when you try to add an event handler to the button. Here’s what a click event listener looks like with the native <button> element:
1 2 3 | <button onclick="alert('Hi, I am a native button!')"> Click me</button> |
And, here’s the equivalent using the div button:
1 2 3 | <div role="button" tabindex="0" onclick="alert('Hi, I am a non-native button!')"> Click me</div> |