Accessibility scanners are useful.
They can find missing alt text. They can flag color contrast problems. They can detect empty links, skipped heading levels, missing form labels, invalid ARIA, and plenty of other problems that deserve attention.
But there is one thing they cannot truly prove:
Whether a real person can use your site with a keyboard.
That matters because keyboard access is not a tiny edge case. It affects people who use screen readers, people with motor disabilities, people using switch devices, people with temporary injuries, power users, and anyone who cannot or does not use a mouse.
A page can pass an automated scan and still fail a keyboard user badly.
That is not a scanner failure. That is a misunderstanding of what scanners can and cannot verify.
A scanner can see code. It cannot experience the path.
Keyboard navigation is about movement, order, visibility, interaction, and recovery.
A scanner may detect that a button exists. It may detect that a link has text. It may even detect some ARIA problems.
But it cannot fully answer questions like:
Can I reach every interactive element using the Tab key?
Can I see where focus is?
Does focus move in a logical order?
Can I open and close menus without a mouse?
Can I operate modals, accordions, tabs, date pickers, dropdowns, maps, and custom widgets?
Can I escape when something traps focus?
Can I complete the full task from start to finish?
That is not just code validation. That is user-path testing.
“Focusable” does not mean “usable”
One of the easiest traps is assuming that if something can receive focus, it is accessible.
That is not enough.
A keyboard user needs to know where they are, what they can do, how to activate something, and how to keep moving.
A link that receives focus but has no visible focus indicator is technically reachable, but practically hostile.
A menu that opens on hover but not on keyboard focus may look fine to mouse users while being unusable to keyboard users.
A modal that opens but does not move focus inside itself can leave keyboard users lost behind the overlay.
A custom dropdown that works only with mouse clicks is not a dropdown. It is a wall.
Scanners may catch pieces of these problems. They usually cannot prove the whole interaction works.
Keyboard testing is a manual responsibility
The basic test is simple:
Put the mouse down.
Use the keyboard.
Start at the top of the page and move through it.
Use:
- Tab to move forward
- Shift + Tab to move backward
- Enter to activate links and buttons
- Space to activate buttons, checkboxes, and certain controls
- Arrow keys where expected, especially in menus, radio groups, tabs, and sliders
- Escape to close menus, dialogs, and overlays
Then ask one brutal question:
Can I actually complete the task?
Not “did the scan pass?”
Not “does the dashboard say zero issues?”
Can a user complete the task?
That is the standard that matters.
Common keyboard failures scanners miss
Here are some of the usual suspects.
Missing visible focus
A keyboard user tabs through the page, but there is no clear outline, underline, border, or visual change showing where they are.
This is one of the fastest ways to make a site unusable.
If the user cannot see focus, they are navigating blind.
Bad focus order
The tab order jumps around the page in a confusing sequence.
It may go from the header to the footer, back to the navigation, into a sidebar, then somewhere in the middle of the page.
This often happens when the visual layout and source order do not match, or when developers use positive tabindex values to force an order.
Keyboard traps
A user tabs into a component and cannot get out.
This can happen with modals, embedded widgets, menus, maps, carousels, and custom controls.
A keyboard trap is not just annoying. It can block the user completely.
Hover-only menus
A navigation menu opens when the mouse hovers over it, but not when a keyboard user focuses it.
To the scanner, the links may exist.
To the keyboard user, the menu may as well be locked.
Custom controls without keyboard behavior
A div styled to look like a button is not automatically a real button.
If it does not receive focus, respond to keyboard activation, and expose the right role/name/state, it is probably broken.
Most of the time, the fix is simple:
Use a real <button>.
Modals that lose focus
When a dialog opens, focus should move into it.
When the dialog closes, focus should return to the control that opened it.
If focus stays behind the modal, disappears, or jumps to the top of the page, keyboard users get punished for interacting.
Hidden content in the tab order
Sometimes users can tab to elements they cannot see.
That often happens when content is visually hidden but not removed from the keyboard path.
If the user can focus something invisible, the page becomes confusing fast.
The dashboard is not the experience
Accessibility dashboards are helpful for tracking work.
They can show trends. They can help teams prioritize. They can make large sites less chaotic.
But dashboards are not users.
A green score does not prove someone can complete a form.
A clean scan does not prove a menu works.
A low issue count does not prove a modal is usable.
A report can support accessibility work, but it cannot replace the work.
Keyboard navigation is one of the clearest examples of that.
What teams should document
If you want to treat keyboard accessibility seriously, document the test.
Not in a giant novel. Just enough to prove that someone checked the actual user path.
For each important page or workflow, record:
- Page or workflow tested
- Browser used
- Date tested
- Tester
- Whether focus was visible
- Whether tab order was logical
- Whether menus/dialogs/widgets worked
- Whether the task could be completed without a mouse
- Any issues found
- Any fixes made
That is good-faith accessibility work.
Not perfect. Not magical. But real.
A simple keyboard test script
Here is a basic checklist teams can use:
- Load the page.
- Put the mouse aside.
- Press Tab from the browser address bar into the page.
- Confirm a skip link appears if the page has repeated navigation.
- Continue tabbing through the page.
- Confirm every interactive element receives visible focus.
- Confirm the order makes sense.
- Activate links and buttons with Enter.
- Activate buttons, checkboxes, and controls with Space where appropriate.
- Open and close menus, modals, accordions, and dropdowns.
- Confirm Escape closes overlays where expected.
- Use Shift + Tab to move backward.
- Complete the main task without touching the mouse.
If the task cannot be completed, the page is not keyboard accessible.
No dashboard score changes that.
The real lesson
Accessibility scanners are valuable tools.
But they are not hands. They are not eyes. They are not users.
They cannot feel confusion when focus disappears.
They cannot get trapped in a modal.
They cannot wonder why a menu opens for a mouse but not a keyboard.
They cannot tell you whether a real person can complete the task.
That part is on the team.
So use the scanner.
Fix what it finds.
But when the question is keyboard navigation, do not ask the dashboard to prove the experience.
Put the mouse down.
Use the keyboard.
Test the path.
Leave a Reply