Flawless Keyboard Navigation and Visual Focus
Author
Redaksi Disabilitas.com
Keyboard Navigation and Visual Focus: Guiding Users Without a Mouse
For many users—including those with motor disabilities, tremors, or simply power users who prefer efficiency—the keyboard is the only navigation tool they have. If a website cannot be operated entirely using a keyboard, it is fundamentally broken.
Adapting guidelines from Practical Web Accessibility by Ashley Firth (Chapter 4: Motor Impairments), this article discusses the anatomy of keyboard navigation, the dangers of manipulating tabindex, and why the visual focus indicator is the lifeblood of non-mouse interaction.
Related Insight
Accessibility in Single Page Applications (SPA: React & Vue)1. DOM Order vs Visual Order
When a user presses the Tab key, the browser moves focus sequentially through interactive elements (links, buttons, form inputs) based on their placement within the HTML code (Document Object Model or DOM).
Problems arise when designers use modern CSS like flex-direction: row-reverse, order, or float to visually move elements in the opposite direction of their HTML order.
The Imminent Danger: If the "Cancel" button is visually on the left and the "Submit" button is on the right, but in the HTML the "Submit" button is written first, a keyboard user will illogically jump to "Submit" first. This violates WCAG Success Criterion 2.4.3 (Focus Order).
The Golden Rule: The visual order of a page must always match the order of its elements within the DOM.
2. Manipulating the `tabindex` Attribute
The tabindex attribute is a powerful tool, but it is frequently abused to the point of destroying accessibility. There are three types of tabindex usage you need to know:
1. `tabindex="0"` (Adding to the Tab Order)
If you are forced to create custom interactive elements using `2. `tabindex="-1"` (Removing from Tab Order, focusable via JS)
This is incredibly useful for container elements like Modal windows or Dropdowns. Elements with `tabindex="-1"` cannot be reached by pressing the `Tab` key, but you can programmatically move focus to them using JavaScript (e.g., `element.focus()`).3. `tabindex="1"` or Greater (STRICTLY PROHIBITED)
Assigning a positive `tabindex` value (like `1`, `2`, `3`) forces that element ahead of all other interactive elements on the page, regardless of its position in the DOM. This creates absolute chaos for Screen Reader and keyboard users as the cursor will jump randomly across the screen. Never use a `tabindex` greater than zero.3. The Danger of Keyboard Traps
According to WCAG 2.1.2 (No Keyboard Trap), a user must not get stuck inside an element while navigating with a keyboard.
Related Insight
WAI-ARIA: Savior or Destroyer of Accessibility?Keyboard traps most commonly occur in:
- Modal Windows (Pop-ups).
- Third-party video players (like legacy Flash widgets or poorly coded iframes).
- Rich Text Editors (WYSIWYG).
If a user uses Tab to enter a text editor, the Tab key inside it is often repurposed to insert an indent (whitespace), meaning the user cannot exit the text box. You must always provide an exit route (e.g., an instruction: "Press Escape to exit the editor").
4. The Focus Indicator (Focus Ring)
Removing the browser's default focus indicator without replacing it is the cardinal sin of front-end design:
/<em> THE GREAT ACCESSIBILITY SIN </em>/
*:focus { outline: none; }
If you do this, keyboard users are literally blind. They have no idea where their "cursor" is.
The Solution: `:focus-visible`
Many designers remove the outline because they think the blue/black ring that appears when clicking a button with a mouse is "ugly." The modern solution is the `:focus-visible` pseudo-class./<em> Removes the outline when clicked with a mouse </em>/
*:focus:not(:focus-visible) {
outline: none;
}
/<em> Shows a thick outline ONLY when navigated via keyboard </em>/
*:focus-visible {
outline: 3px solid #ff5722;
outline-offset: 4px;
}
5. Conclusion
Keyboard navigation is the bedrock of almost all assistive technologies. If a website is not keyboard-friendly, it is almost certain it will not work well for screen readers, voice commands, or Switch devices. Do not rely on CSS to arrange interactive layouts; trust your pure HTML logical structure.
References
The technical explanation of DOM vs visual order, the dangers of positive `tabindex` attributes, and visual focus indicator solutions are extracted directly from the practical troubleshooting in the book Practical Web Accessibility by Ashley Firth (Chapter 4: Motor Impairments). The Keyboard Trap rules refer to the absolute mandates of the WCAG Level A standard.What do you think?
Give your reaction to this article