Test your own site with a keyboard in five minutes

Before anyone quotes you for an accessibility audit, you can run the first test yourself. No software, no training, no budget approval — and on most small-government sites it finds something in the first thirty seconds.

Move the mouse away. Open your homepage in a desktop browser, click once in the address bar to park focus above the page, and start pressing Tab. Tab moves forward through everything a person can interact with, Shift+Tab moves back, Enter activates. That's the whole toolkit.

Minute one: the first Tab press

Press Tab once and look at the very top of the page.

Something should appear that wasn't there a moment ago: a small "Skip to main content" link, normally hidden until it takes focus. Press Enter on it and focus should land past the navigation, in the body of the page.

If nothing appears, that's 2.4.1 Bypass Blocks, Level A. It sounds cosmetic. It isn't: without it a keyboard user tabs through your whole header and menu — often thirty to sixty presses — on every page, before reaching a word of content.

Minute two: the header and the menu

Keep tabbing. Don't look for what's focused; look for whether you can tell what's focused. There should be a clear outline moving from item to item.

If it disappears, that's 2.4.7 Focus Visible, Level AA. The cause is almost always outline: none in the stylesheet — someone removed the browser's default ring because it looked untidy and never replaced it. Focus is still moving; you just can't see it.

The second failure here is dropdowns. If your nav submenus open only on mouse hover, tabbing either skips their contents entirely — unreachable links, a 2.1.1 Keyboard, Level A failure — or focus walks into items positioned off-screen but still focusable, and you press Tab twenty times with the ring nowhere on screen.

Minute three: the widgets

Tab into anything that isn't plain content: a carousel, an accordion, an embedded map, a chat bubble, a cookie banner, an inline PDF viewer.

You are looking for one thing: can you get back out. Tab a few times, then Shift+Tab a few times. If focus circles inside the component forever and neither Tab nor Escape releases it, that is 2.1.2 No Keyboard Trap, Level A — a total failure, not a partial one. The user cannot reach the rest of the page without closing the tab. Embedded third-party widgets are the usual culprit.

Minute four: a real form

Go to whichever form matters most — contact, a permit request, the utility payment start page — and complete it with the keyboard only. Three things to watch for:

• A button you can't reach — Tab goes past and it never highlights. That's a <div> styled to look like a button, failing 2.1.1 Keyboard and 4.1.2 Name, Role, Value, both Level A. Real <button> and <a href> elements are focusable for free.
• Something that happens the instant focus arrives — a date picker springing open, a page jumping, a menu firing. 3.2.1 On Focus, Level A: receiving focus must not change the user's context on its own.
• A field whose only label is the gray hint text inside it. That's a label that vanishes the moment you type, which fails 3.3.2 Labels or Instructions, Level A.

Minute five: does the order make sense

Shift+Tab back up the page and watch where the ring goes compared to where your eye expects it. If it jumps header to footer to sidebar and back, that's 2.4.3 Focus Order, Level A.

The part that surprises the developer, not the clerk

Tab order follows the source order of the HTML, not the visual layout. Modern CSS can put a block anywhere on screen regardless of where it sits in the document — grid placement, flexbox order, absolute positioning. So a page that looks perfectly ordered can tab in a sequence nobody would ever choose, and no visual inspection will ever reveal it.

The fix people reach for makes it worse. Setting tabindex="1", tabindex="2" and so on does not renumber the page — it creates a second tab sequence that runs entirely before every naturally focusable element in the document. One positive tabindex on one button means Tab visits that button first, ahead of your skip link, your logo, and your menu. The only values that belong in modern markup are 0 (focusable in its natural place) and -1 (focusable by script, not by Tab). Everything else is fixed by moving the element in the source.

One tool tip while you're testing: in Chrome's DevTools, open the three-dot menu → More tools → Rendering, and turn on Emulate a focused page. Otherwise the moment you click into DevTools the page loses focus and the ring you were chasing disappears.

What to do with what you found

Write down what you hit and where. A skip link, a visible focus style, and turning fake buttons into real ones are cheap mechanical fixes that clear three Level A criteria and help everyone using the site. A keyboard trap inside a vendor widget is a conversation with that vendor, better had now than inside a remediation agreement.

The test proves failures, not compliance. But five minutes with one key is a far better opening position than a scan report you can't interpret.

If the five minutes turned up more than you'd like, I can take it from there.