Why it matters
Keyboard users move through a page with Tab, and three things go wrong again and again: the order jumps around because of a positive tabindex or CSS that reorders the layout, focus disappears because outline: none removed the only indicator, and focus lands on things nobody can see, like links inside aria-hidden or off-screen content. Checking by hand means tabbing through every page at every width.
This analyser renders your HTML and CSS in a sandboxed frame, works out the Tab sequence the way browsers do (positive tabindex values first in ascending order, then everything else in source order, skipping disabled, hidden and inert content), and then actually focuses each element, comparing its computed outline, shadow, border, background and colour before and after to see whether anything visibly changes. Each stop is checked for an accessible name, a role, aria-hidden ancestors, off-screen position and whether Tab moves back up the page. The order is drawn over the preview as a numbered path, so a layout reordered by flex-direction or grid shows up at a glance.
How it works
- InputA page or component
- In your browserRendered and focused stop by stop
- OutputThe Tab path drawn, with problems per stop
Where it fits in a designer's workflow
- Plan
- Design
- Build
- Test
- Launch
By the numbers
Show the numbers as a table
| # | Element | Name | tabindex | Problems |
|---|---|---|---|---|
| 1 | button.add | Add to basket | 3 | tabindex="3" jumps it ahead of the page order. |
| 2 | a.logo | Hartley Oak home | Tab goes back up the page here (from item 1), against reading order. | |
| 3 | a | Tables | OK | |
| 4 | a | Chairs | OK | |
| 5 | button.search | (no name) | No accessible name. | |
| 6 | input#qty | Quantity | No visible focus style: nothing changes when it's focused. | |
| 7 | div.thumb | Photo 1 | 0 | Focusable div with no role: announced as plain text. Tab jumps right to left here (from item 6): the layout order doesn't match the source order. |
| 8 | div.thumb | Photo 2 | 0 | Focusable div with no role: announced as plain text. |
| 9 | a | Winter sale | Inside aria-hidden: screen readers say nothing when it gets focus. | |
| 10 | a.offscreen | Care guide | Off screen or tiny when focused, so sighted keyboard users lose track of focus. |
How to use it
- Paste the HTML and CSS.
- Pick the viewport width.
- Follow the numbered path on the preview.
- Fix the red stops first: no focus style, aria-hidden and positive tabindex.
FAQ
Why is positive tabindex bad?
Any tabindex above 0 jumps ahead of everything else on the page, so the first Tab press goes to that element instead of the skip link or header. Use tabindex="0" and put elements in the right source order.
What counts as a visible focus style?
Any change in outline, box-shadow, border, background, text colour or underline when the element is focused. WCAG 2.4.7 requires one; 2.4.13 in WCAG 2.2 AAA asks for a clear, high-contrast one.
Why does CSS order matter?
flex-direction: row-reverse, order and grid placement move things visually but not in the Tab sequence, so focus seems to jump around (WCAG 2.4.3, Focus Order).
Can it find keyboard traps?
Not ones made by scripts, since scripts don't run here. It flags the static causes, like focus reaching content behind an open dialog. Test widgets and embedded players by hand.
Why does the skip link matter?
Without one, keyboard users tab through the whole header and navigation on every page before reaching the content (WCAG 2.4.1, Bypass Blocks).
