Using a Site Without a Mouse: What We Found on Our Own

Take your hand off the mouse. Now walk your own site: Tab, Tab, Enter. Reach the form, fill it in, send it. Most owners try this for the first time only when someone suggests it, and they stall around the third screen.

We walked our own site this way last week. One thing broke, but it broke instructively, and that's what the rest of this is about.

Who web accessibility is actually for

There's a comfortable assumption that accessibility concerns hospitals, banks and government portals, while an ordinary business can skip it. Comfortable and wrong.

Here's who runs into an inaccessible interface:

• People who are blind or have low vision. A screen reader speaks the page to them. If a button is written in the code as a plain rectangle, the screen reader has nothing to say about it.
• Anyone whose trackpad just died. Temporary, but happening right now. The keyboard is the only way left to reach your order button.
• People with tremor or limited motor control. Landing a cursor on a small link is hard work. Tab is more reliable.
• Anyone who enlarges text. Past forty that's half your audience, and plenty of sites fall apart at 200% zoom.
• Keyboard users by habit. Developers, accountants, anyone for whom the mouse is slower than their hands.

Add search engines to the list. Google's crawler moves through a page roughly the way a screen reader does: structure, headings, image descriptions. What makes a page comprehensible to a blind visitor makes it comprehensible for indexing too. It's a rare case where two separate problems yield to one move.

What WCAG is

WCAG stands for the Web Content Accessibility Guidelines, published by the W3C, the same consortium behind web standards in general. In practice it's a list of concrete requirements for a page, from text contrast to how forms behave, grouped by how strict they are.

There are three levels:

• Level A. The floor, below which the site simply doesn't work for some people.
• Level AA. The working target. This is the level legislation in most countries points to.
• Level AAA. The ceiling. Very few sites meet it in full, and that's fine: some of its requirements clash with certain kinds of content.

In Europe this stopped being goodwill. The European Accessibility Act took effect in the summer of 2025 and covers online shops, banking services, e-books, transport and booking platforms. Small companies under two million euros in turnover get relief, but «this doesn't apply to us» is wearing thin. Several countries now require a separate page, an accessibility statement, where the owner records in writing what the site conforms to and what is still outstanding.

What we found on our own site

Our site runs in three languages, switched by a flag in the header. It looked right and worked flawlessly with a mouse.

The keyboard pass said otherwise. The flag button itself was a real button in the code, so Tab reached it and the list opened. The three options inside that list stayed plain markup blocks with nothing marking them as clickable. Tab didn't see them, Enter did nothing to them.

The result was a trap. Someone would open the language list from the keyboard and could neither pick a language nor work out where the navigation had gone: the next Tab press sent them somewhere further down the page, past the open list.

The fix took half an hour. Each option got role="button" and tabindex="0", which is what makes a block reachable by keyboard and meaningful to a screen reader. We added Enter and Space handling, a label with each language's own name (Українська, English, Español), and aria-current on the active one so it announces as «button, selected» rather than just «button».

The uncomfortable part is how long this survived. The site passed reviews and scored well in automated tools, and not one of them surfaced it. A keyboard trap is visible only to a real person actually pressing Tab.

A ten-minute website accessibility check

Nothing to install, a browser is enough. Treat the six points below as a starting website accessibility checklist.

1. The Tab pass. Open the homepage and press Tab until you've been round the page. Two questions along the way: can you see where the focus is, and did you get stuck anywhere. What tools label as wcag focus comes down to exactly this, a visible ring on the active element. If the stylesheet carries outline: none with nothing put back, that ring is gone and the visitor is moving blind.
2. Menus and dialogs. Open each one from the keyboard and try closing it with Escape. Contact forms, promo pop-ups and mobile menus break far more often than ordinary links.
3. 200% zoom. Ctrl and plus, four times. Text should stay readable and buttons shouldn't climb over each other.
4. Contrast. Light grey on white looks refined in a mockup and disappears on a phone in daylight. The floor for body text is a ratio of 4.5 to 1, and any online contrast calculator will tell you where you stand.
5. Image descriptions. Every meaningful image needs an alt attribute describing what it shows. Decorative ones keep an empty alt so the screen reader skips them instead of reading out a filename.
6. Headings in order. One H1 per page, then H2, with H3 nested inside. Skipping levels breaks things: a screen reader builds its outline from them, and that outline is how blind visitors move around.

After that you can run Lighthouse, built into Chrome under the developer tools. It gives a score and a list of complaints, and there are plenty of similar tools: an accessibility checker like axe DevTools or WAVE will flag things Lighthouse misses. Keep one correction in mind though. Any automated website accessibility checker catches roughly a third of real problems, which is why serious website accessibility testing always pairs the tooling with a human walking the page. Ours never caught the language switcher.

What only shows up in the code

Some things surface neither under Tab nor under an automated pass.

• Focus that escaped a modal. The dialog is open, Tab is wandering the page behind it. Nothing looks wrong, because the dialog covers the background.
• Reading order that doesn't match the layout. Columns were rearranged in the stylesheet while the code kept the old order. The eye sees one thing, the screen reader reads another.
• Silent confirmations. The form submitted, the green message appeared, the screen reader said nothing. Fixed with an attribute that marks the region as live.
• Form field labels. A hint inside the field vanishes the moment someone starts typing, and it stops being clear what goes there.

What it costs to fix

During development, nothing. None of the above is extra work, it's ordinary care: call a button a button, leave the focus ring alone, describe the image. A developer doing it from the start spends exactly the same amount of time.

On a finished site the price depends on what it's built from. Targeted fixes like ours are a matter of hours. If the site sits on a builder where markup is generated for you and half of it isn't yours to touch, the platform sets the ceiling.

A word on overlay widgets that promise accessibility in one line of code. They drop a panel over the site with buttons for larger text and a high-contrast theme. That doesn't solve anything, because the code under the panel is unchanged, and some screen readers get more confused with the overlay than without it. Hundreds of lawsuits in the US in recent years have named sites that had exactly such a panel installed.

Where to start

If this is all new, start with the Tab pass. Ten minutes, no tooling, and you'll know straight away whether you have a problem. What you do next depends on the scale: a handful of fixes you can brief to your own developer, or website accessibility services if the markup needs reworking from underneath.

If it turns up breakages and their source isn't obvious, that's a website audit, which covers how to check systematically and in what order to fix. We ran the same kind of teardown on our own loading speed earlier, and the cause there also turned out not to be the one we expected. And if accessibility has to be retrofitted into a template-based site, first look at where a builder's limits actually sit: not everything on this list can be fixed there at all.

← Back to blog