What is Focus Order Visualizer?

Paste any HTML and see the keyboard tab order mapped out. Numbered markers appear on each focusable element so you can spot navigation problems at a glance. Built for accessibility auditors and developers checking WCAG compliance.

The visualizer detects links, buttons, form inputs, textareas, select menus, details/summary disclosure widgets, contenteditable regions, and anything with an explicit tabindex. Each focusable element gets a numbered badge plus a flag for whether its position comes from DOM order (natural) or an overriding tabindex value (custom). It also scores the page out of 100, flags controls with no accessible name (the icon-only button problem), and shows how many interactive elements never become reachable by Tab. Export the findings as a plain-text report or a structured CSV for audit records and bug trackers.

How to use

1. Paste HTML into the editor or upload an HTML file to check its tab order.
2. Numbered markers appear on each focusable element (links, buttons, inputs) showing the tab sequence.
3. Read the accessibility score and the issues panel, fix any out-of-order, unlabelled, or keyboard-unreachable elements, then export the findings as a text report or CSV.

When to use

• Pre-audit check before submitting a page for WCAG 2.1 AA certification.
• Tracking down a tab-order regression after a layout or component refactor.
• Validating a modal or off-canvas menu traps focus where it should.

Result

An accessibility consultant pastes a client's signup form HTML. The visualizer catches the 'Submit' button taking focus before the 'Terms of Service' checkbox, because a positive tabindex reordered them. That's a WCAG 2.4.3 failure.

FAQ

Is using tabindex with a positive number always wrong?

Almost always, yes. Positive tabindex (1, 2, 3...) lifts elements out of DOM order and jumps the user around the page unpredictably. Stick to tabindex='0' to make non-interactive elements focusable, or tabindex='-1' to remove from tab order while keeping programmatic focus.

What does 'natural' versus 'custom' mean in the order list?

Natural means the element's tab position comes from where it sits in the HTML source. Custom means a positive tabindex value forced it into a different slot. Custom positions are flagged because they're the most common source of WCAG 2.4.3 failures.

Do hidden elements show up in the focus order?

If they're truly hidden (display:none or visibility:hidden) the browser skips them, and so does the visualizer. But aria-hidden alone does not remove focusability, which is a common bug. The list will show those, and you can tell from the rectangle data whether they're visible.

Does this catch missing focus traps in modals?

It shows you the order, not whether keyboard focus escapes a modal. Paste the modal's open HTML, and check whether the first and last focusable elements look like they sit inside the dialog. If the tab order jumps to body content, the trap is missing.

Why is an element I expected to be focusable missing from the list?

Disabled inputs, anchors without href, and divs without a tabindex attribute are skipped because the browser won't focus them. Add tabindex='0' if a div needs to be reachable, or add href to anchors, or remove the disabled attribute.

Related Tools