Keyboard Accessibility: Can Users Navigate Your Website by Keyboard?

Keyboard accessibility means every link, button, and form on your website works without a mouse. In this guide, Talha Aslan and team walk through focus styles, tab order, skip links, and the traps hidden in menus and modals. At the end, you get a ten minute test plan and a checklist you can run on your own site today.

That sounds simple. In practice, however, many sites fail on the first attempt. The menu refuses to open, the cookie banner will not close, or the focus outline disappears entirely. In short, a design can feel flawless with a mouse and still break down for keyboard users.

This article covers only one slice of the wider topic. We explain the full picture, including color and text alternatives, in our guide to web accessibility and WCAG standards. Here, we focus on the keyboard and on focus order.

Who relies on keyboard navigation?

Many teams assume only blind users need keyboard support. Screen reader users do depend on the keyboard; however, they are far from the only group. People with limited fine motor control, tremors, or pain when gripping a mouse also prefer the keyboard or devices that behave like one.

On top of that, some of this audience is temporary. Think of someone with a wrist in a cast, a laptop owner with a broken trackpad, or an accountant who tabs through forms for speed. In addition, switch devices, voice control software, and some eye tracking systems send keyboard events behind the scenes.

• Blind and low vision visitors who use screen readers.
• People with limited motor control who cannot use a mouse.
• Users with a temporary injury or faulty hardware.
• Power users who move through forms with the Tab key.
• Anyone whose assistive technology emulates keyboard input.

In other words, keyboard support is not a nice extra for a tiny minority. Instead, it is a core usability layer. When it is missing, every one of these visitors leaves before reaching your form.

Which WCAG success criteria cover the keyboard?

WCAG (Web Content Accessibility Guidelines) is the international accessibility standard published by the W3C. Its keyboard rules sit across several success criteria, and each one targets a different problem. The table below summarizes the criteria we meet most often in the field and what each one looks like on a real website.

According to the W3C Understanding document for 2.1.1 Keyboard, the only exception covers functions that depend on the path of the user's movement, such as freehand drawing. Everything else, including drag and drop, resizing, and moving objects, needs a keyboard equivalent.

What is focus, and why must the focus indicator stay visible?

Focus is the state that decides which element receives keyboard input at a given moment. A mouse user follows the pointer with their eyes. A keyboard user, by contrast, follows only the focus indicator. That indicator usually takes the form of an outline, an underline, or a color shift around the element.

Without a clear indicator, the user walks in the dark. They press Tab, assume something changed, and still have no idea where they are. Therefore, the W3C 2.4.7 Focus Visible criterion requires every keyboard operable interface to offer a mode where the focus indicator is visible.

By default, browsers draw an outline of their own. Still, that outline does not stand out on every background. A thin blue line on a dark header can almost vanish. So instead of trusting the default, we recommend designing a strong focus style that fits your color palette.

Why is removing the focus outline the most common mistake?

The keyboard error we see most often in design reviews is a stylesheet rule that switches the focus outline off completely. The reason is usually cosmetic. A designer or client clicks a button, notices the outline, and decides it looks broken. As a result, a single line of CSS strips keyboard users of their sense of direction.

The fix is not to delete the outline. Instead, decide when it should appear. The :focus-visible selector, which modern browsers support, does exactly that. The browser uses its own heuristics to tell keyboard focus from mouse focus. Consequently, the outline usually stays hidden after a click and shows up after a Tab press.

Here is an example scenario. A service website has primary buttons that work perfectly with a mouse, yet a keyboard visitor cannot tell which button holds focus. In that case, we first remove the rule that hides the outline. Then we add a thick, brand colored ring with :focus-visible. That way the design language stays intact, and keyboard users find their way again.

How do you design a good focus indicator?

Above all, a good focus indicator stands out equally well in every part of the page. Remember that one color rarely works on every background. You need a dark line on light areas and a light line on dark areas. For that reason, we often use a two tone approach: a dark inner ring and a light outer ring.

• Keep the outline at least 2 pixels thick, because thin lines disappear easily.
• Leave a small gap between the element and the outline with outline-offset.
• Make sure the outline contrasts strongly with the surrounding background.
• Do not rely on color alone; add a change in shape or thickness too.
• Use the same visual language for buttons, links, form fields, and cards.

Measure contrast instead of eyeballing it. For example, our color contrast checker lets you test your focus color against header, body, and footer backgrounds one by one. The stricter Focus Appearance criterion in WCAG 2.2 sits at level AAA. Even so, its logic about thickness and contrast gives you a solid starting point.

How do you set the tab order?

Tab order is the sequence focus follows each time you press Tab. Browsers build that sequence from the order of elements in the HTML source. In other words, source order, not the visual layout, defines your focus order.

That is also where trouble starts. When you rearrange elements with CSS, for instance by flipping a column with flexbox or grid, the order on screen and the Tab order drift apart. The user expects the next button at the top, yet focus jumps to the bottom of the page. The W3C 2.4.3 Focus Order criterion exists to prevent exactly this mismatch.

1. Code the page in a logical reading order first: header, main menu, main content, sidebar, footer.
2. Build the visual layout so it does not break that order.
3. Test the order separately on mobile and desktop layouts.
4. Place injected content, such as alerts or panels, right after the element that triggers it.

So the secret to a good tab order is not extra code. It is clean, well structured HTML. As a bonus, screen readers then read the page with the same logic.

When should you use tabindex, and when should you avoid it?

tabindex is the HTML attribute that controls whether an element joins keyboard focus. According to the MDN documentation, there are three cases. A value of 0 adds the element to the natural order. A value of -1 removes it from the Tab sequence but keeps it focusable from a script. Positive values reorder the sequence by hand.

Specifically, MDN advises against positive values. An element with tabindex="1" jumps ahead of every natural element on the page, which makes the order unpredictable. Moreover, those numbers become impossible to manage as the site grows.

• tabindex="0": Makes a custom widget, such as your own tab control, focusable.
• tabindex="-1": Lets you move focus to an error message or a modal heading from a script.
• Positive values: Almost never; fix the source order instead.

On the other hand, links, buttons, and form fields already accept focus. You do not need to add tabindex to them. Unnecessary additions clutter the code, and sometimes they even make one element receive focus twice.

What is a skip link, and how do you add one?

A skip link sits at the very top of the page and takes the user past the menu, straight to the main content. It usually reads "Skip to content." Normally it stays off screen, then appears the first time a visitor presses Tab.

The value shows up on busy navigation, so consider an example. In this example scenario, a corporate site with a 30 link menu, a language switcher, and a search box in its header. Without a skip link, keyboard users must tab through every one of those items on every page. The W3C 2.4.1 Bypass Blocks criterion asks for a way to skip such repetition, and it lists the skip link among its sufficient techniques.

1. Add the link right after the opening body tag, as the first focusable element.
2. Point it at the id of the main content area.
3. Hide it visually, but show it clearly at the top of the screen when it receives focus.
4. Press it and confirm with Tab that focus really moved into the main content.

Also, marking the main area with a main element and the menu with a nav element gives screen reader users another way to jump. Still, a visible skip link remains essential for keyboard users who do not use a screen reader.

Why do dropdown menus fail keyboard users?

In practice, most dropdown menus open only on mouse hover. When a keyboard user focuses the top level item, nothing happens. Either the submenu never appears, or its links take focus while staying invisible. The second case confuses people even more, because focus keeps vanishing into hidden links with every Tab press.

A sturdier approach ties the submenu to a button. The top level label stays a link, while the arrow next to it becomes a separate button. When the user presses Enter or Space on that button, the submenu opens and the aria-expanded state changes. As a result, screen readers announce whether the menu is open or closed.

• Links inside a closed submenu should stay out of the Tab order.
• Escape should close an open submenu and return focus to its button.
• The submenu should close on its own once focus leaves it.

Likewise, the same rules apply to mobile navigation. The hamburger icon must be a real button, the panel must receive focus, and the close button must work from the keyboard. We cover the mobile navigation decision itself in our hamburger menu guide.

How do you prevent focus problems in modal dialogs?

A modal dialog is a layer that opens on top of the page and pauses interaction with the content behind it. From a keyboard perspective, you can make two opposite mistakes: focus escapes the modal, or the user can never leave it. Both break the experience. Fortunately, the modal dialog pattern in the W3C ARIA Authoring Practices Guide describes the right behavior clearly.

1. When the modal opens, move focus to a suitable element inside it, usually the first focusable item or the heading.
2. Let Tab and Shift+Tab cycle within the modal, wrapping from the last item to the first.
3. Let Escape close the modal.
4. When the modal closes, return focus to the button that opened it.
5. Keep the page content behind the modal out of focus while it stays open.

In practice, step four is the one teams forget most. If focus lands at the top of the page after the modal closes, users lose their place and must scroll down again on a long page. For that reason, storing the trigger element and returning focus to it on close is a small but valuable detail.

The native dialog element in modern browsers handles part of this behavior by itself when you open it with showModal. Even so, do not trust that assumption on any project until you test it by hand with the keyboard.

What separates a keyboard trap from a modal focus lock?

At first glance, the two look identical, since focus stays inside a specific area in both cases. The difference lies in the exit. A modal focus lock is a deliberate design choice, and the user can leave at any moment with Escape or a close button.

A keyboard trap, however, is a bug. The W3C 2.1.2 criterion states that if focus can enter a component, the keyboard alone must also move focus away from it. If leaving requires a nonstandard method, the page must tell users how. Embedded video players, third party map widgets, chat windows, and some rich text editors are classic sources of this trap.

• Modal lock: Deliberate, with a clear exit, closes with Escape.
• Keyboard trap: Unintended, with no exit, forces a page reload.
• How to test: Tab into every embedded element, then try leaving with Tab, Shift+Tab, or Escape.

For example, if a chat bubble grabs focus and never lets go, visitors cannot reach the rest of the page. In that situation, we check the third party settings first. If no fix exists, we evaluate alternatives.

Why do sticky headers and cookie banners hide focus?

Sticky headers stay pinned to the top of the screen while the page scrolls. Cookie banners and chat bubbles usually stick to the bottom. When a keyboard user presses Tab, the browser scrolls the focused element into view. Yet that element can end up right under one of these fixed layers.

As a result, focus exists, but the user cannot see it. Criterion 2.4.11, which arrived with WCAG 2.2, says a focused component must not hide entirely behind content the author added. It sits at level AA, so any site that targets AA should account for it.

Still, the practical fixes are simple. Set the CSS scroll-padding-top value to match the height of the sticky header. Then the browser places the element just below the header instead of under it. For the cookie banner, put it first in the focus order and make sure it does not cover the page until someone dismisses it. Above all, test these fixed layers on mobile, where the screen is small.

Why do div buttons not work with the keyboard?

When you build a button from a div or span instead of a button element, the browser gives it no built in behavior. The element takes no focus, ignores Enter and Space, and screen readers do not announce it as a button. Since mouse clicks still work, teams usually miss the bug during design.

A real button element, by contrast, provides all of that for free. Likewise, anything that changes the page should be an a element, and anything that triggers an action should be a button. The distinction matters for both keyboard and screen reader users, because they expect a link to take them somewhere and a button to do something.

Consider an example scenario. A whole product card responds to clicks, yet the card is a div wired only to mouse events. Keyboard users never reach the cards and cannot open product details. The cleanest fix is to turn the product title inside the card into a real link and extend its click area with CSS. You can find broader design principles for these elements in our article on interactive web design elements.

How should forms, sliders, and carousels behave with a keyboard?

Forms are where your site earns money, so give them the most time during keyboard accessibility testing. Every field needs a visible label, focus should move through fields in a sensible order, and an error should send focus to the field or to an error summary. Also, custom select boxes and date pickers should respond to the arrow keys.

Carousels and sliders bring a different problem. An auto rotating carousel can pull a focused link off the screen while the user sits on it. Therefore, add a pause button, hold rotation while focus is inside the carousel, and build the previous and next controls as real buttons.

• Link each label to its field programmatically.
• Confirm that users can reach and press the submit button with the keyboard.
• Keep links in hidden carousel slides out of the Tab order.
• Build accordion headers as buttons and announce their expanded state.

We discussed the conversion side of forms in our lead form design article. Here, we stay focused on keyboard behavior.

Does keyboard accessibility affect SEO and conversions?

Google has not described keyboard accessibility as a direct ranking signal. For that reason, we never promise that adding a focus outline will lift your rankings. That said, the indirect links are strong, and ignoring them would be a mistake.

First, a keyboard friendly site usually rests on clean, semantic HTML. Real links and buttons also help search engine crawlers understand your pages. For example, fake links that work only through a click handler offer no address for a crawler to follow.

The conversion side is even clearer. A visitor who cannot reach your quote form by keyboard cannot submit it, no matter how convinced they are. So we suggest treating the keyboard test as a natural step in conversion focused web design. Tools such as Lighthouse reflect part of keyboard accessibility in their score, but not all of it.

How do you run a keyboard test in ten minutes?

For a keyboard test, you need no special software, just a browser and ten minutes. Push the mouse aside, or even unplug it. Then try the three most important pages of your site in turn: the homepage, one service page, and the contact page.

1. Click the address bar and press Tab once. Did a skip link appear?
2. As you tab forward, can you see where focus sits at every step?
3. Does focus follow the reading order on screen, or does it jump?
4. Can you open submenus with Enter or Space and close them with Escape?
5. Can you dismiss the cookie banner and any chat bubble from the keyboard?
6. Open a modal. Did focus move inside, did Escape close it, and did focus return to the trigger?
7. Can you fill in and submit the form from start to finish? Does an error move focus?
8. Check whether a sticky header or bottom bar hides the focused element.
9. Finally, does the same order hold when you move backward with Shift+Tab?

Next, log every "no" in a table with the page address and element name. That gives your developers a clear, repeatable bug list. Finally, repeat the test in the mobile view of your browser's device emulation mode with an external keyboard.

Can automated tools catch keyboard issues?

Automated accessibility scanners are valuable, yet they catch only part of the keyboard problems. For instance, they can flag positive tabindex values, unlabeled form fields, and some kinds of interactive elements that do not accept focus. An algorithm cannot reliably judge whether the focus order makes sense, though, or where focus goes after a modal closes.

That is why we work in two layers. First, an automated scan clears the easy errors. Then we run the manual test plan above. Lighthouse also lists items to verify manually at the end of its accessibility report. We walk through Lighthouse step by step in our Lighthouse testing guide.

In short, keyboard accessibility problems can remain even with a perfect automated score. The score is a starting point; the real check is picking up the keyboard and actually using the site.

Example scenario: reaching a quote form by keyboard

Specifically, the scenario in this section is fictional, and we built it to show a typical chain of errors. On a consulting firm's website, a visitor wants to get from the homepage to the quote form. On the first Tab press, focus lands on the logo link without any outline, because the stylesheet turned the outline off.

Next, the user reaches the menu. The "Services" submenu opens only on hover, so it stays hidden from the keyboard. Its twelve links, however, still take focus, and the user gets lost among invisible items. After that, the cookie banner at the bottom completely covers the focused "Get a quote" button.

Then comes the fix plan, which has four steps. Add a strong outline with :focus-visible, convert the submenu to a button driven pattern, add a skip link, and move the cookie banner to the start of the focus order with a working close button. After those steps, the user completes the same path in a few Tab presses and can follow it by eye.

Keyboard accessibility checklist

We recommend running the list below before any new page goes live and after every major design change. You can check each item by hand in a few minutes.

• I can reach every link, button, and form field on the page with Tab.
• The focus indicator stands out on every background with enough contrast.
• Focus order matches the visual reading order.
• No element uses a positive tabindex value.
• A working skip link sits at the start of the page.
• Submenus open from the keyboard and close with Escape.
• Links in closed menus and hidden slides do not take focus.
• Focus moves into a modal on open and returns to the trigger on close.
• No embedded component creates a keyboard trap.
• Sticky headers and cookie banners never hide the focused element.
• Interactive elements use real a and button tags.
• Form errors send focus to the right field.

Also, each item maps to a criterion or practice from the sections above. As a result, you can add this list to a project template and share it with your design, development, and content teams.

How do you plan focus order during design?

Most keyboard accessibility issues start in the design file, not in the code. If a designer draws only the default and hover states and never defines focus, the developer skips it too. That is why we treat the focus state as a required part of every component in a design system.

In practice, you draw a separate focused look for buttons, links, form fields, cards, and menu items. Next, add a short note beside each screen that numbers the Tab order. That small step makes life much easier for developers. The designer decides the order, and the developer simply implements it.

When you combine this habit with a clear contrast strategy, as described in our article on how to use contrast in design, keyboard support stops being a last minute patch. Instead, it becomes a quality standard from day one.

How we build this into your website

When we design a new site, we include keyboard accessibility and focus order from the first wireframe. We add focus styles to the design system, build menus and modals with the patterns above, and run a manual keyboard test before launch. On an existing site, we first create a bug list with the test plan in this article, then fix issues in order of priority.

So if you are not sure how your site behaves with a keyboard, our web design service covers this work, and we set it up for you. Share your page count and platform, and we will prepare a clearly scoped proposal. For an accessible, fast, and conversion focused website, visit our web design page to request a quote.