Keyboard Accessibility Tester – Online Check Tab Order

Keyboard accessibility ensures that all interactive elements on a webpage can be operated using only a keyboard. This is essential for users with motor disabilities, visual impairments (who use screen readers), and power users who prefer keyboard shortcuts. The Web Content Accessibility Guidelines (WCAG) 2.1 require all functionality to be operable through a keyboard interface (Success Criterion 2.1.1). Without proper keyboard access, millions of users may be unable to navigate your site effectively.

Tab order is the sequence in which focus moves between interactive elements when a user presses the Tab key. The browser determines this order based on: (1) elements with positive tabindex values (sorted numerically), followed by (2) elements with tabindex="0" or no explicit tabindex (in DOM order). Elements with tabindex="-1" are excluded from the tab sequence but can still receive focus programmatically via JavaScript.

• tabindex="0" — Element is focusable via Tab key, inserted in DOM order. This is the recommended value for making non-interactive elements (like <div>) keyboard-accessible.
• tabindex="positive number" — Element receives focus before tabindex="0" elements, in numerical order. Generally discouraged as it can create confusing navigation.
• tabindex="-1" — Element is removed from the tab sequence but can be focused with JavaScript. Useful for modals, custom widgets, or skip-link targets.

Positive tabindex values (like tabindex="1", tabindex="3") create a brittle, hard-coded navigation order that often diverges from the visual layout. When the DOM structure changes, these values must be manually updated across the entire codebase. They also make it nearly impossible to maintain a logical tab order in complex applications. Best practice is to use only tabindex="0" and tabindex="-1", relying on natural DOM order for tab sequencing.

A skip link (or "skip navigation" link) is typically the first focusable element on a page. It allows keyboard users to bypass repetitive navigation menus and jump directly to the main content. Without skip links, users must tab through every navigation item on every page load — which can mean dozens or even hundreds of key presses. A well-implemented skip link is visually hidden but becomes visible when focused, providing a critical keyboard shortcut for accessibility.

To manually test keyboard accessibility: (1) Unplug your mouse or disable your trackpad. (2) Use Tab to navigate forward through all interactive elements. (3) Use Shift+Tab to navigate backward. (4) Verify that every interactive element receives focus with a visible focus indicator. (5) Confirm that the tab order follows a logical visual flow. (6) Use Enter or Space to activate buttons and links. (7) Use Escape to close modals or dropdowns. This tool's sandbox above lets you practice and verify these behaviors.

Common issues include: missing focus indicators (users don't know where they are), focus traps (can't escape a modal or widget), illogical tab order (jumping around the page unpredictably), inaccessible custom controls (divs with click handlers but no keyboard support), hidden focusable elements (off-screen elements still in the tab order), and positive tabindex chaos (conflicting numerical values creating confusing navigation). This tester helps you identify these issues in your own components.

WCAG 2.1 includes several criteria related to keyboard access: 2.1.1 Keyboard (Level A — all functionality operable via keyboard), 2.1.2 No Keyboard Trap (Level A — focus can always move away), 2.4.3 Focus Order (Level A — meaningful sequence), 2.4.7 Focus Visible (Level AA — visible focus indicator), and 2.1.4 Character Key Shortcuts (Level A — single-key shortcuts must be remappable or disableable). Meeting these criteria is essential for legal compliance in many jurisdictions.

This sandbox tool is designed for learning and demonstration purposes. To test your own website, use browser developer tools: in Chrome DevTools, go to the Accessibility panel to inspect the accessibility tree and focus order. You can also use the Lighthouse audit tool to automatically detect keyboard accessibility issues. For comprehensive testing, combine automated tools with manual keyboard-only navigation of your entire site.

Screen readers like NVDA, JAWS, and VoiceOver follow the same DOM-based tab order for keyboard navigation. However, screen reader users also have additional navigation commands (like heading shortcuts, landmark navigation, and element lists) that go beyond simple tabbing. A logical tab order benefits all users — sighted keyboard users, screen reader users, and those using switch devices or voice control. Proper semantic HTML and ARIA landmarks further enhance the screen reader experience beyond basic tab order.

Focusable elements can receive keyboard focus through any means (Tab key, JavaScript .focus(), mouse click). This includes all interactive elements plus those with tabindex="-1". Tabbable elements are a subset — those reachable via the Tab key. An element with tabindex="-1" is focusable but not tabbable. Understanding this distinction is crucial for building accessible widgets like modals, where you might programmatically focus a container while keeping internal elements in the natural tab flow.