Keyboard Navigation & Tab Order Tester
Audit webpage HTML for positive tabindex anti-patterns and non-native clickable elements missing keyboard support — two of the most common keyboard-accessibility issues.
tabindex value (which breaks natural tab order) and non-native clickable elements (like <div onclick>) that have no tabindex at all (which keyboard users cannot reach). It does not execute JavaScript and cannot detect runtime keyboard traps, focus-management bugs inside modals, or key handlers attached separately via addEventListener. Use it as a fast first pass, then manually Tab through the page to confirm real-world behavior.Technical Deep-Dive: Keyboard Accessibility Testing
📌 On this page
1. Why keyboard access matters beyond compliance
Keyboard navigation is not a niche accommodation — it's the baseline interaction model for a large slice of real visitors: people with motor disabilities who cannot use a mouse, screen reader users who navigate almost exclusively via Tab and arrow keys, power users who find keyboard shortcuts faster, and anyone whose trackpad or mouse has temporarily failed. WCAG 2.1.1 requires that every piece of functionality on a page — links, buttons, form controls, custom widgets — be reachable and operable using only a keyboard, with no mouse-only dead ends. A site that looks perfect visually can still be entirely unusable for a keyboard-only visitor if even a handful of interactive elements were built without this in mind.
2. How this tool actually scans your HTML
When you submit a URL, the backend fetches the raw HTML response over a server-side request (protected by SSRF allowlisting — private IPs, loopback addresses, and cloud metadata endpoints are always blocked) with a 10-second timeout, then runs a regular-expression pass over the markup to find every native interactive element (<a>, <button>, <input>, <select>, <textarea>) plus any element carrying a tabindex attribute or an onclick attribute. This is a snapshot of the HTML as delivered by the server — it does not run any client-side JavaScript, so DOM changes made after page load (React/Vue hydration, dynamically inserted widgets) are not reflected in the audit.
3. The positive tabindex anti-pattern in detail
Every element on a page has an implicit position in the natural tab order based on where it sits in the DOM. Setting tabindex="1" (or any positive number) removes an element from that natural order and forces it to the very front of the sequence, ahead of everything else — and if multiple elements use positive values, the browser tabs through them in ascending numeric order before touching anything else on the page. The practical result is a tab sequence that jumps around unpredictably and no longer matches the visual reading order, which is disorienting for anyone navigating by keyboard. This tool flags every positive-tabindex element it finds and subtracts 20 points per occurrence from the 100-point score.
4. Fake clickables: div/span with onclick
A native <button> element is automatically focusable, appears in the tab order, and responds to both Enter and Spacebar out of the box — all for free, with zero extra code. A <div onclick="..."> gets none of that: it is invisible to the Tab key and cannot be activated by any keyboard input unless the developer manually adds tabindex="0" and a matching keydown handler for Enter/Space. This tool flags any non-native element with an onclick attribute but no tabindex attribute at all, since that combination guarantees a keyboard user has no way to reach or trigger it. Each occurrence subtracts 15 points from the score.
5. What static scanning cannot see
Static HTML analysis has a hard ceiling: it can only evaluate what is literally present as attributes in the markup. It cannot detect a genuine runtime keyboard trap (a modal or widget whose JavaScript intercepts Tab/Escape and never lets focus leave), it cannot detect keyboard handlers attached via addEventListener in an external script rather than an inline onclick attribute, and it cannot verify that a custom widget's focus order matches its visual layout once JavaScript has finished rendering. These require either manual keyboard testing or a browser-automation tool that actually executes the page's scripts. Treat this tool's output as a fast, zero-effort first pass that catches two extremely common and easy-to-introduce mistakes — not as a substitute for hands-on testing.
6. A manual keyboard-testing checklist
To catch what static scanning can't, unplug your mouse (or just don't touch it) and Tab through the entire page from the top. Confirm: every interactive element receives a visible focus outline, the tab order follows the visual/reading order with no unexplained jumps, every modal or dropdown can be opened, used, and closed with keyboard alone, pressing Escape closes overlays and returns focus to the triggering element, and there is no point where Tab gets "stuck" cycling through the same handful of elements forever. This five-minute manual pass, combined with this tool's automated attribute scan, covers the large majority of real-world keyboard accessibility failures.
Frequently Asked Questions
Why should positive tabindex values (tabindex="1", tabindex="2") never be used?
Positive tabindex values force the browser to focus those elements before all other natural DOM elements, breaking the expected reading order and creating unpredictable focus jumps for keyboard users. Only use tabindex="0" (to make custom elements focusable) or tabindex="-1" (to programmatically focus an element).
Why is <div onclick="..."> considered an accessibility failure?
Non-interactive elements like <div> and <span> are not focusable via keyboard Tab and do not respond to Enter or Spacebar keys. Sighted mouse users can click them, but keyboard-only and screen reader users cannot interact with them at all.
What is WCAG 2.1.1 (Keyboard Accessible)?
All website functionality must be operable through a keyboard interface without requiring specific timings for individual keystrokes, ensuring users with motor disabilities can navigate effortlessly.
Can this tool detect real keyboard traps (a widget that swallows focus and never lets it leave)?
No, and this is an important limitation to understand. A true keyboard trap happens at runtime, usually inside JavaScript event handlers that call preventDefault() on Tab or Escape, or focus-management logic in a modal that never restores focus on close. This tool performs static HTML pattern matching only — it never executes JavaScript, so it cannot observe what a script does when a key is pressed. It can only flag two structural anti-patterns that are visible directly in the markup: positive tabindex values and non-native clickable elements missing tabindex. Manual testing (Tab through every interactive element with a real keyboard) is still required to catch runtime traps.
Does this tool detect keyboard handlers added with JavaScript (addEventListener)?
No. The scan only inspects HTML attributes present in the raw markup, such as an inline onclick attribute. If a site attaches its click or key handlers separately in a <script> file via addEventListener, that logic is invisible to a static HTML scan. A <div> with a JS-attached click handler and no tabindex will still be correctly flagged as inaccessible (since the tabindex is still missing), but a <div> that a script quietly makes keyboard-operable via a manually added keydown listener would not be recognized as accessible by this tool.
What counts as a "focusable element" in the scan results?
The scanner counts every native interactive element (<a>, <button>, <input>, <select>, <textarea>), plus any element carrying an explicit tabindex attribute of 0 or higher, plus any non-native element (like <div> or <span>) that has an onclick handler but no tabindex at all — since that last category represents a fake-clickable that a keyboard user cannot reach.
Does this tool enforce SSRF security checks?
Yes. All live audits enforce strict SSRF safeguards, blocking requests to private networks, loopbacks, and cloud metadata IPs.