Keyboard Focus Is a Feature, Not an Afterthought
Not everyone uses a mouse. Some people navigate with a keyboard because of a motor disability, some use screen readers that rely on keyboard navigation and many experienced users simply find the keyboard faster. For all of them, two questions decide whether a website or app is usable: can I reach everything with the Tab key, and can I see where I am?
We treat keyboard support as a feature that every screen must have, not a polish item for later. Here is what that involves.
Every interactive element is reachable
Links, buttons, form fields, menus, tabs, toggles and dialog controls must all be reachable with the keyboard, in a sensible order that follows the visual layout. The most common way to break this is to build a clickable element out of a plain box instead of a real button or link. It may look identical and respond to a mouse, but the keyboard skips it entirely.
Our rule is to use real interactive elements for interactive things. Buttons are buttons. Links are links. When a custom component is unavoidable, it must take keyboard focus and respond to the expected keys, such as Enter and Space.
Focus must be visible
When an element has keyboard focus, people need to see it. Browsers draw a default focus outline, and many designs remove it because it looks out of place. Removing it without a replacement leaves keyboard users lost.
Our designs replace the default with a clear, consistent focus indicator, a strong outline in a contrasting color with a little space around the element. On this website, it uses our plum brand color. In the admin area, it follows the shared design standard. Focus indicators appear for keyboard use and stay out of the way for mouse clicks, which modern browsers support directly.
Menus and dropdowns
Navigation menus with dropdowns are a frequent problem. A dropdown that opens only on mouse hover is unusable from the keyboard. In our website headers, dropdown parents are real buttons that open with the keyboard and tell assistive technology whether they are expanded, and the links inside are reachable with the Tab key. Good dropdowns also close with the Escape key and return focus to the button that opened them, which is the behavior we test for.
Dialogs manage focus
A dialog that opens on top of a page should take focus, keep focus inside itself while open and return focus to the button that opened it when it closes. Without that, a keyboard user may keep tabbing through the page hidden behind the dialog without realizing it. Our admin dialogs follow that pattern, and important actions inside them, like confirm and cancel, are reachable in a predictable order.
Skip links and landmarks
Long pages with large headers benefit from a "skip to main content" link at the very top, which lets keyboard users jump past navigation they have already heard many times. Clear page landmarks, such as header, navigation, main content and footer, also help screen reader users move around quickly. Our site layouts mark their header and footer as landmarks, and we treat skip links as part of a complete keyboard experience.
Sticky elements must not hide focus
Sticky headers and floating buttons can cover the element that currently has focus as someone tabs down a page. We check that focused elements scroll into view without being hidden behind fixed elements, adjusting spacing where needed.
How we test
The simplest test is also the most revealing: put the mouse away and use the screen with only the keyboard. Tab through every element, open every menu and dialog, submit every form. Watch the focus indicator the whole time. If it disappears, jumps unexpectedly or gets trapped, something needs fixing.
We include that keyboard pass in reviews of new and redesigned screens, alongside checks for contrast, reduced motion and phone layouts. You can read about motion in supporting reduced motion and about forms in accessible forms.
Good for everyone
Keyboard support is essential for some people and helpful for many more. Power users move faster. People with a temporary injury can still work. And the discipline of building real buttons and visible states tends to produce cleaner, more reliable interfaces for everyone.
Frequently asked questions
How do I test keyboard accessibility?
Put the mouse aside and navigate with Tab, Shift and Tab, Enter, Space and Escape. Every interactive element should be reachable with a visible focus indicator.
Is it okay to remove focus outlines?
Only if you replace them with an equally visible focus style. Removing focus indicators makes a site unusable for keyboard users.
Why does my dropdown menu not work with the keyboard?
Menus that open only on hover cannot be reached by keyboard. Use a real button to open the menu and support Enter, arrow keys and Escape.
Related Posts
Accessible Forms: Labels, Errors and Focus
Forms are where people sign up, pay, register and ask for help. Here is how we make them clear and usable for everyone, including people using screen readers or keyboards.
Checking Every Screen at Phone Width
Many people manage their organizations from a phone. Here is why we check every screen at phone width, what usually breaks and how we fix it before customers notice.
Writing Error Messages People Can Act On
An error message is often the moment someone decides whether to keep trusting software. Here is how we write messages that explain what happened and what to do next.
Comparing the Old Site and the New Site Screen by Screen
After a website moves platforms, small differences hide in plain sight. Here is how we compare the old and new sites at desktop and phone sizes before calling a move complete.
Why Every Import Starts With an Automatic Backup
Imports change a lot of data at once, so we never start one without a verified recovery point. Here is how the automatic backup step works and why it is not optional.
Comments (0)
No comments yet. Be the first to share your thoughts!