Website Tools

Keyboard Navigation Checker

Find keyboard barriers before your users do. The checker lists the tab order with each element’s role and accessible name, and flags positive tabindex values, click handlers on elements that cannot be focused, interactive ARIA roles without tabindex, links without href, javascript: links, duplicate access keys, autofocus, missing or broken skip links, tabindex="0" on non-interactive elements and CSS that removes the focus outline without a visible :focus-visible replacement.

  • Encrypted connection
  • No sign-up
  • Free to use
Analyse pasted HTML instead

The page is fetched once by our server and its HTML and CSS are analysed in your browser as inert text. Automated checks cannot press keys: always finish with a manual Tab-through.

How to use Keyboard Navigation Checker

  1. Enter a URL or paste HTML.
  2. Click Check keyboard access.
  3. Fix the barriers listed.
  4. Finish with a manual Tab-through.

Keyboard Navigation Checker features

Tab order

Up to 60 focusable elements with names.

Click-only elements

div and span with onclick.

Focus styles

outline: none in your CSS.

Skip link

Checks the target exists.

WCAG references

2.1.1, 2.4.1, 2.4.3, 2.4.7.

Paste mode

For staging pages.

When to use Keyboard Navigation Checker

  • Release QA.
  • Component library reviews.
  • Accessibility audits.
  • Teaching accessible development.

Keyboard Navigation Checker FAQ

Can it press Tab for me?

No – it analyses the code. Always test with the keyboard yourself.

Why is positive tabindex bad?

It moves elements ahead of everything else, so the focus order no longer follows the layout.

Is outline: none always wrong?

Only when no other visible focus style replaces it; :focus-visible styles are fine.

Keyboard first

Many people navigate with a keyboard or switch device. If something works with a mouse only, it does not work for them at all.

How it works: a URL is fetched once by our server through a guarded client that only connects to public addresses; the HTML (and, where needed, the stylesheets) is then analysed in your browser as inert text – scripts on the page never run. Pasted HTML is analysed without any request. Nothing is stored.

Automated testing has limits: tools can reliably find missing names, invalid ARIA, broken references, skipped headings and similar code problems, but roughly two thirds of WCAG criteria need human judgement – whether alt text is meaningful, whether focus order makes sense, whether content is understandable. Every result says what still needs manual testing.

The checks follow WCAG 2.2 and WAI-ARIA 1.2, the standards behind the European Accessibility Act, the Americans with Disabilities Act guidance, Section 508 and EN 301 549. Each finding names the success criterion so you can look it up and include it in a report or ticket.

Related tools on this site cover the rest of an accessibility review: the HTML accessibility checker, WCAG contrast checker, accessibility colour analyzer, keyboard navigation checker, ARIA validator, alt text generator, heading structure checker and the accessibility statement generator.

Who it is for: front-end developers checking a release, designers reviewing a component library, content editors, QA testers and agencies preparing accessibility audits for clients. No account, plugin or installation is needed.

Other useful tools