Skip to content

KeylensTest the keyboard path users actually take.

Keylens drives a real browser, follows the tab order, and reports where keyboard navigation breaks.

Try it in one command

Install Keylens where your tests already live.

$ npm install -D @progress/keylens
Read the guide

See it in action

Tab through it. See exactly what breaks.

Keylens drives a real browser, presses Tab, and renders the actual focus path — not a static markup check.

npx @progress/keylens audit
$ npx @progress/keylens audit sample-interface-url
Crawling tab order in a real browser…

✓ keyboard-trap
✗ unreachable-elements        1 issue
✓ focus-order-mismatch
✓ tabindex-abuse
✗ missing-focus-indicator     3 issues
✗ skip-link                   1 issue
✓ focus-not-obscured
✓ focus-after-interaction
✓ roving-tabindex-broken

────────────────────────────────
2 errors, 1 warning · score 89/100
focus order · 23 stops
A small generic sample page with a nav, hero, three feature panels, a subscribe form and a footer.

View the full CLI output

Why runtime keyboard testing? ​

Static analysis can identify interactive elements and inspect their semantics. Keylens adds the missing runtime question: can a person actually move through the page with a keyboard?

Static analysis

What the markup allows

Inspect roles, names, states, and relationships in the rendered DOM.

Keylens

What the browser delivers

Press Tab, observe focus, and report the controls and states users can reach.

Built for CI and local debugging ​

Run the same audit from a terminal, a test script, or an MCP client. Use the terminal report while fixing a page, then switch to JSON for a repeatable CI contract.

Run an audit

$ npx @progress/keylens audit https://example.com
Explore the CLI reference →

Automate the result

$ npx @progress/keylens audit https://example.com --output json
Set up CI/CD →

Released under the Apache License 2.0.