How does this analyze keyboard accessibility without a browser?

It parses your HTML with a small string tokenizer rather than a real DOM, so it runs identically in the browser, on a server, and in tests — and it never executes your markup. It identifies focusable elements (native controls plus anything with tabindex), resolves each one’s role and best-effort accessible name, and checks the structural patterns that cause keyboard failures. Because it can’t see your CSS or runtime JavaScript, it focuses on what the markup alone reveals and reminds you to verify focus visibility separately.

Why is a with an onclick flagged as an error?

A plain or isn’t in the tab order and has no role, so keyboard and switch users can’t reach or activate it — even though it works with a mouse. That fails WCAG 2.1.1 Keyboard. To make it operable you need three things together: tabindex="0" to make it focusable, an appropriate role so assistive tech announces it, and a keydown handler that responds to Enter (and Space for buttons). In almost every case the simpler, more robust fix is to use a native or that already has all of that built in.

What’s wrong with positive tabindex values?

Any tabindex greater than 0 pulls an element to the front of the tab order, ahead of everything that relies on natural DOM order. As soon as you have more than one, the sequence becomes a puzzle: focus jumps between the positive-tabindex elements first, then falls back to the document order, skipping around the page. It’s also a maintenance trap — every new interactive element has to be slotted into the numbering. Use tabindex="0" to add something to the natural order, or just order your DOM correctly and use no tabindex at all.

What does the “tab stops” count mean?

It’s the number of elements that actually land in the sequential keyboard tab order — what a user reaches by pressing Tab repeatedly. It counts native controls and elements with tabindex of 0 or higher, while excluding things with tabindex="-1" (focusable only programmatically), disabled controls, hidden elements, and anchors without an href. The full focusable list can be longer than the tab-stop count because it also shows elements that are focusable by script but not by Tab.

Does it check that my focus indicators are visible?

It can’t — focus styling lives in CSS, which static markup analysis doesn’t see. That’s why it always surfaces an info note pointing at WCAG 2.4.7 Focus Visible: every focusable element needs a clear :focus-visible indicator with at least 3:1 contrast against its background and a thickness of around 2px, and you should never remove the outline without providing a replacement. Use the live sandbox tab to Tab through real widgets and confirm the indicator is obvious.

What are the key patterns and when do I need them?

The Key patterns tab lists the keyboard interactions assistive-tech users expect from each widget per the WAI-ARIA Authoring Practices Guide — for example, tabs move with the arrow keys and Home/End while exposing a single tab stop, menus close on Escape and support first-letter typeahead, and dialogs trap focus and restore it on close. You only need to implement these by hand when you build a custom widget; native HTML elements already behave correctly, which is why using them is almost always the better choice.

Keyboard Navigation Tester

Find the keyboard traps in your markup before your users do. Paste HTML and the analyzer lists every focusable element in tab order with its role, tabindex, and accessible name — then flags the real bugs: positive tabindex, click-only divs that fail WCAG 2.1.1, links with no href, and tabindex on roleless elements. Tab through a live sandbox to watch focus move, browse the WAI-ARIA key-interaction patterns for every widget, and generate ready-to-paste keydown handlers.

About this ToolHow it works, benefits & use cases

Most keyboard-accessibility problems are invisible until someone unplugs their mouse. This tester finds them in your markup first. Paste an HTML fragment or a whole page and it walks the source in order, listing every focusable element as a numbered tab sequence with the role, tabindex, and accessible name a browser would expose — so you can see at a glance whether the tab order matches the reading order. Alongside the order it runs a levelled audit (error / warning / info) for the failures developers ship most: positive tabindex that hijacks the page order, a click-only <div> with no role, tabindex, or key handler (a WCAG 2.1.1 failure that locks out keyboard and switch users), an <a> with no href that can't be focused, and tabindex on a roleless element that's focusable but never announced. Because the parsing is pure string work — not a real DOM — it runs anywhere and never executes your markup. Three more tabs round it out: a live sandbox of real widgets you can Tab through while it shows which element has focus, a reference of the WAI-ARIA key-interaction patterns for every common widget, and a generator that writes ready-to-paste keydown handlers.

How to Use

1Open the “Analyze HTML” tab and paste your markup, or load the bundled example to see seeded issues.
2Read the numbered focus-order list on the left — each entry shows the tag, resolved role, tabindex, and accessible name.
3Check the issues card for errors (mouse-only controls, broken links), warnings (positive tabindex), and info notes.
4Switch to “Live Tab sandbox” and press Tab to feel the real focus order; the readout names the focused element.
5Use “Key patterns” to wire custom widgets correctly, and “Handler generator” to copy a keydown handler.

Key Benefits

Lists every focusable element in true DOM/tab order with role, tabindex, and accessible name
Flags WCAG 2.1.1 failures — click-only divs missing role, tabindex, and key handlers
Catches positive tabindex, tabindex on roleless elements, and links with no href
Pure string parsing — analyses markup without a browser and never executes it
A live, real-DOM sandbox to Tab through with a live “focus is on” readout
Reference of WAI-ARIA keyboard patterns for buttons, tabs, menus, dialogs, comboboxes, sliders and more
Generates copy-paste keydown handlers and bundles focus-management best practices

Common Use Cases

Auditing a component’s markup for keyboard traps before it ships
Proving a clickable card is mouse-only and needs a role + tabindex + key handler
Spotting positive tabindex that reorders a form into a confusing sequence
Confirming the tab order in a fragment matches the intended reading order
Looking up the exact arrow-key behaviour expected of a custom tablist or menu

Focusable elements in order

5 tab stops

1
<a>link
name: Home
2
<a>linktabindex=2
name: Pricing
3
<button>buttontabindex=0
name: Sign in
4
<input>searchbox
name: Search the docs
5
<button>button
name: Close

1 keyboard issue to fix

<div> has a click handler but is mouse-only — it's missing tabindex="0", a role, a keydown handler (Enter/Space). Keyboard and switch users can't operate it. Add the missing pieces, or far better, use a native <button>.· 2.1.1 Keyboard (A)<div class="card" onclick="select(this)">
tabindex="2" forces this <a> to the front of the tab order. Positive tabindex is an anti-pattern: it creates a confusing order and a maintenance bomb as the page grows. Use tabindex="0" (or rely on DOM order) instead.· 2.4.3 Focus Order (A)<a href="/pricing" tabindex="2">
<a> with no href isn't focusable and behaves like generic text. Add an href to make it a real link, or use a <button> if it triggers an in-page action.· 2.1.1 Keyboard (A)<a onclick="openMenu()">
Positive tabindex values are mixed with tabindex="0" elements. Tab will jump to the positive ones first and only then fall back to DOM order, so the sequence skips around the page unpredictably.· 2.4.3 Focus Order (A)
tabindex="0" on a <button> is redundant — it's already in the tab order. Harmless, but you can drop it.<button type="button" tabindex="0">
Visible focus styles can't be detected from HTML alone. Verify every focusable element has a clear :focus-visible indicator (≥3:1 contrast, ≥2px) — never `outline: none` with no replacement.· 2.4.7 Focus Visible (AA)

HTML to analyze

Paste a fragment or a whole page — the analyzer walks it in source order.

Shareable analysis

Send this exact input to a teammate

<nav aria-label="Primary">
  <a href="/">Home</a>
  <a href="/pricing" tabindex="2">Pricing</a>
  <button type="button" tabindex="0">Sign in</button>
</nav>

<main>
  <a onclick="openMenu()">Menu</a>
  <div class="card" onclick="select(this)">
    Selectable card
  </div>
  <input type="search" placeholder="Search the docs" />
  <button aria-label="Close">✕</button>
</main>

Keyboard access is the floor, not the ceiling

WCAG 2.1.1 requires that everything doable with a mouse is doable with a keyboard. The two failures that ship most often are a <div onclick> with no role, tabindex, or key handler (invisible to keyboard and switch users) and positive tabindex, which reorders the page into a maze. This tester parses your markup statically — no browser needed — to surface both, plus links with no href and focusable elements with no role.

What it can and can’t see

Static analysis catches structural bugs in the markup. It can’t see your CSS, so it always reminds you to verify a visible :focus-visible indicator (WCAG 2.4.7) and to Tab through the real thing — use the live sandbox tab to feel the order yourself, and the key-patterns tab to wire custom widgets the way the WAI-ARIA Authoring Practices Guide expects.

Was this tool helpful?

Share Your Experience

Help others discover this tool!

Share on

Keyboard Navigation Tester

How to Use

Key Benefits

Common Use Cases

Focusable elements in order

Keyboard access is the floor, not the ceiling

What it can and can’t see

Was this tool helpful?

Share Your Experience

Related tools

Frequently Asked Questions - Keyboard Navigation Tester