Keyboard accessibility is often reduced to one rule - make sure everything works with Tab, but there’s so much more to it.
Here are 10 things about keyboard navigation that even people who build websites sometimes overlook:
Tab doesn’t mean “move to the next thing I can see”
Keyboard focus generally follows the order of elements in the HTML/DOM, not their visual position on the screen. So CSS can make a page look perfectly ordered while keyboard focus moves through it differently.
Tab is only one part of keyboard navigation
Inside components such as tabs, menus and grids, arrow keys may move between items, while Enter, Space, Home, End or Escape can have specific roles. Accessible keyboard interaction is about following the expected interaction pattern for the component.
A keyboard trap can make an entire website effectively unusable
Focus can enter a component but, because of poor implementation, become impossible to move away from using the keyboard. The mouse still works, the page still looks fine, but the keyboard user is stuck.
tabindex=”0” doesn’t turn a <div> into a button
It makes the element focusable. It doesn’t give it the semantics or keyboard behaviour of a button. This is one of those cases where “keyboard accessible” and “actually accessible” are very different things.
A component can be visually first but keyboard-later
CSS properties such as order can rearrange content visually without changing its underlying DOM order. The screen says “start here”, but the keyboard may say something else.
Focus can move somewhere you can’t see
A sticky header, footer, cookie banner or modal can cover the element that currently has keyboard focus. The focus hasn’t disappeared - it has simply become obscured.
Removing the focus outline can remove someone’s sense of location
For a sighted keyboard user, focus is a navigation signal. Without a visible focus indicator, they may know what they just did but have no idea where they are now.
tabindex=”-1” doesn’t mean “not accessible”
It means the element isn’t in the normal Tab sequence, but it can receive focus programmatically. This is extremely useful for things like moving focus to a newly opened dialog or a heading after navigation.
Native HTML gives you keyboard behaviour for free
A real <button>, <input>, <select> or link already comes with browser-supported interaction behaviour. Rebuilding the same thing with a <div> means you may have to recreate that behaviour yourself correctly. That’s a lot of responsibility for something that could have been a button.
Everything being reachable doesn’t mean the experience is good
A page can technically work with a keyboard and still require dozens of Tab presses, have a confusing focus order, or make the user hunt for where focus went.
