Testing keyboard functionality
Testing for keyboard accessibility boils down to a few questions:
- Can you access all the content on the page? Links, buttons, etc.
- If there are dialogs, is the focus maintained properly? Whenever a dialog is open, the focus should remain inside that element and not go behind the open dialog.
- Do you actually know where you are on the page when you move from one element to another?
-
Are there keyboard shortcuts that use only letter (including upper- and lower-case letters), punctuation, number, or symbol characters?
- The user needs to be able to either turn these off or change the shortcuts. On basic websites these are quite rare.
- Is there a skip to content type link as the first focusable element on the page? It can be always visible or become visible when focused.
- If there are more repeating blocks on the site, can those be skipped? E.g. does the element have a skip link before all the content?
- Is the focus order logical?
When you navigate with a keyboard, the idea is to jump from one focusable element to the next. The focus isn't supposed to move to e.g. text content or headings. Do you know where you are?
The item you are focusing on should have a visible enough focus style. According to WCAG, the browser default style is enough to pass the criterion, but it's better to have more visible styles. Also, WCAG 2.2 might bring on changes.
How to operate the keyboard
-
Use the
tabkey to move from one element to the next. -
Use
shift+tabto move from one element to the previous one. -
To visit a link, press
enter. -
To press a button, press
enterorspace. - When inside a radio button set, press arrow keys to move between the options.
Safari has a setting that allows tabbing
If you use Safari, know that you will need to first allow tabbing or otherwise it's not going to work.
Go to Safari / Preferences / Advanced and System Preferences / Accessibility: Press Tab to highlight each item on a web page
Some basic form controls to test
Element semantics
You might have heard the saying "A link is not a button" or vice versa. And this is not a minor thing. Links and buttons are semantic elements with different functions. A button does something on the page, for example, opens a modal. A link will take you somewhere, usually to another page.
We all have probably met the button-looking links, which are quite common these days. While they can be great for catching people's eye and getting them to click on these "CTA buttons", there is also a downside. These can be confusing for users because you can't visually tell if is it a link or a button. And if you are a user who activates buttons with a spacebar but the element is actually a link... well. Try what happens with the link below this paragraph.
This is a link buttonAnother thing that is not a button is a <div>. Use <button> for elements that open and close modals. That will save you time and reduce the number of reported bugs.
Elements with multiple links to it
You might have seen implementations of cards where you have separate links to the target. For example, in an image, heading and then a link button. While this technically is allowed, it is not recommended for several reasons. It can get tedious to try to go through a list of items when you have multiple links for one item. Accessibility rules also dictate that you should always link to the same target with the same link text. This implementation breaks that as well.
This type of approach can be also often seen in search results. Avoid it if you can.
Note that for a screen reader user a link with the URL as the text is not an optimal user experience.
Your tasks
Practice keyboard usage.
- Basic usage: move from one element both forwards and backwards, activate buttons and links.
- Navigate forms. Make sure you know how to use the different types of basic form elements.
- Activate the link button on this page with the space key. What happened?
- Check the last example on this page with multiple links for the same element and the button at the end.