The third rule of ARIA is simple but essential: all interactive components must be keyboard accessible. Users should be able to navigate and interact with your website using only a keyboard.
Key keystrokes to support:
- Tab – Moves forward through interactive elements.
- Shift + Tab – Moves backward. Always test both directions – some websites break backward tabbing.
- Escape – Used to close things like modals or mega menus.
- Spacebar – Activates buttons (but not links).
- Enter – Activates both buttons and links.
- Arrow keys – Commonly used for radio buttons, tabs, and menu navigation.
Developer best practices:
- Use semantic HTML elements like
<button>,<a>, and<input>. These come with built-in accessibility support, so you don’t have to manually script keyboard behavior. - Avoid using
<div>and<span>for interactive elements unless absolutely necessary – they require extensive JavaScript to function properly. - Keep semantic structure intact. For example, don’t place a heading inside a button. Instead, wrap the button inside the heading if needed – buttons should always be the innermost element.
Important accessibility standard to follow:
- Avoid custom keystrokes unless they can be turned off or remapped. WCAG 2.1.4 requires this to prevent conflicts with assistive technologies or user-installed tools.
- In a study of 13,000 pages, only three required custom keystroke mapping, so in most cases, it’s unnecessary and should be avoided.
By sticking to standard keyboard interactions and semantic HTML, you’ll reduce complexity and significantly improve your site’s accessibility.
Transcript
The third rule of ARIA is that interactive components must be keyboard accessible. This is probably one of the easiest to understand. We must be able to use our websites with only a keyboard.
Tab
What’s important to know for developers is that we need to use standard keystrokes pretty much all the time. The first one to know is tab. You should be able to reach everything within the website using Tab. Also, Shift Tab should go backwards through the website.
Both directions are important to test for, as I have seen some developers who have broken the website on Shift Tab.
Escape
The next one is Escape. This is how we close or leave things. For example, a modal window that has appeared. We should be able to exit it by clicking on Escape.
Also for submenus, especially mega menus, we need to be able to close them via the Escape key.
Space Bar
The next one is Spacebar. Spacebar activates buttons. Buttons are different from links. Enter activates both buttons and links.
The difference between the two, a button performs an action, a link goes to a location. For example, a button would open a submenu a menu, open a modal, or submit a form.
A link goes to a location. It could be a jump link that scrolls down the page to a specific spot on the page, or it could be a link that goes to a new location.
Arrow Keys
Finally, the arrow keys. These are used most often on radio buttons, but they’re also frequently used on menus, tabs, and other items.
Whenever possible, we want to use our semantic elements as this gives us a whole lot less JavaScript. If we try and code everything up with <div>s, we are going to need a ton of JavaScript to handle all of that interaction.
If we just use the default semantic elements like buttons, links, and inputs, all of that is handled for us by the browser, and we just have to verify that it’s actually working.
Buttons
Speaking of buttons, this is a really important note for developers.
Buttons kill child semantics. Here I have an example of a h3 with a button inside it, and then the label, “question”. This would commonly be used for an accordion or a frequently asked questions module. This is the correct way to code it. I have seen, however, a lot of developers who have put button and then tried to put their heading inside of the button.
Unfortunately, this kills the semantics of the heading, and the heading is completely lost. So remember, buttons are always the innermost element.
Avoid Custom Keystrokes
Finally, a quick note to say avoid custom keystrokes. WCAG 2.1.4 says that if you create a custom keystroke, then you must be able to have it turned off or remapped.
This is because people have tons of their own tools installed on their websites with all sorts of custom keystrokes, and we don’t want to override or interfere with what they’re already using. When Deque did a study of 13,000 pages, only three of them had issues with this custom keystroke.
Custom keystroke mapping, actually needing to do that is extremely rare. Just don’t do it with your applications.
I hope you enjoyed this video. If you did, please give it a like, a share, and subscribe to the channel for more information on web accessibility.