A website is usable by keyboard when every function can be reached and operated without a mouse, the order of focus makes sense and you can always see where focus is. Those three conditions map directly to WCAG success criteria, and most failures come from custom components, aggressive styling and sticky page furniture.
Why keyboard access matters
The W3C explains that keyboard access matters for people with no vision, people with low vision who struggle to track a pointer, people with hand tremors and people using keyboard emulators such as switch devices, speech input and on-screen keyboards. The requirement is that everything a page does works through a keyboard interface. The exception is path-dependent input such as freehand drawing.
Start with native elements
Links, buttons, form fields and select menus are keyboard accessible by default. Failures usually appear when a developer builds a button from a generic container and forgets keyboard behaviour. The W3C lists as common failures relying only on pointer-specific event handlers and emulating links in ways that break keyboard behaviour. Use the native element first and reach for custom widgets only when you must. This matters for interactive websites, where sliders, tabs and drag interfaces are the usual trouble spots.
Focus order
The W3C’s focus order criterion requires that focusable components receive focus in an order that preserves meaning and operability. Points worth knowing:
- Focus order does not have to match the visual layout exactly, but it must keep the relationships the layout implies.
- Making the DOM order match the visual order is a listed sufficient technique and the simplest to maintain.
- Misusing tabindex to force an order is a documented failure.
- A dialog or menu should sit next to its trigger in the sequence, or focus should move into it deliberately.
- Forms that jump between unrelated fields fail.
Skip links
Repeated blocks such as navigation and headers make keyboard users tab through the same links on every page. The bypass blocks criterion requires some mechanism to skip them. The first listed technique is a link at the top of the page that goes straight to the main content. Landmarks and headings are also accepted. A skip link is typically hidden until it receives focus, then shown clearly.
Visible focus
Under the focus visible criterion (Level AA), any keyboard-operable interface needs a mode where the focus indicator is visible. Two documented failures are using script to remove focus when an element receives it and styling outlines so the indicator disappears. Removing the default outline without a replacement is the most common cause on business sites.
Practical rules for a custom indicator:
- Use a clear outline or border, not a subtle colour shift.
- Make sure it contrasts with the background. The W3C notes that focus indicators are usually non-text content and must meet the 3:1 non-text contrast requirement. See colour contrast and readable text.
- Keep it visible for as long as the element has focus.
Sticky headers and cookie banners
WCAG 2.2 added the Level AA criterion Focus Not Obscured (Minimum). A focused component must not be entirely hidden by author-created content. Partial obscuring is allowed. The W3C names fixed headers and footers as common causes, and says a sticky footer can pass when CSS scroll-padding keeps the focused item in view. A sticky cookie banner fails if it covers the focused component, but passes if it is modal, uses scroll-padding or closes when it loses focus.
A five-minute keyboard test
- Put the mouse aside and press Tab from the top of the page.
- Check that a skip link appears and works.
- Tab through the whole page: can you always see focus, and does the order make sense?
- Open every menu, dialog and form with the keyboard, and close each with Escape or an obvious control.
- Scroll with focus behind the header and banner: is the focused item ever fully hidden?
- Submit a form and read the error handling.
| Symptom | Likely cause |
|---|---|
| Focus vanishes | Outline removed in CSS |
| Focus jumps around | Misused tabindex or reordered markup |
| Cannot open menu | Mouse-only event handlers |
| Focus hidden under bar | Sticky header without scroll-padding |
Limits
Keyboard testing covers one part of accessibility. Screen reader behaviour, labelling and the rest of WCAG still need checking, and this article is general guidance rather than a conformance audit.
Where Radiance Impact fits
Radiance Impact’s Technology division designs and builds business websites and interactive pages, and keyboard behaviour is part of building them properly. To discuss a project, contact us or read about Technology.
