Our new web application looked flawless — until one evening, when I tried an experiment and controlled it using only the keyboard, without the mouse. No clicking, just Tab, Shift+Tab, arrow keys, Enter and Escape. The result? I felt like I was in a room with no light, bumping into invisible walls and occasionally getting stuck in a corner. In short, an eye-opening experience. And not just for me: every product manager, designer and developer should have a similar experience, because it shows how easily an otherwise excellent product can fail if we underestimate accessibility.

Why does it matter?

Because there is a sizable group of users who have no choice but to rely on the keyboard. Some people can’t use a mouse at all because of hand or vision impairments; others have severe tremors or limited finger mobility. Blind users rely on screen readers and will not pinch themselves without a keyboard. And even perfectly healthy “power users” sometimes prefer keyboard shortcuts for speed. We can make life difficult or easy for all of these people, depending on whether our website is keyboard-friendly or not.

Invisible focus: when you don’t know where you are

The first problem hit me in the eye — it didn’t hit, and that was the problem. When I started scrolling through the page with the tab, I couldn’t see what my focus was on at all. No highlight box, no underline, just nothing. It was like playing a text adventure RPG blindly: I know I‘m somewhere, but I have no idea where. Yet for keyboard control, this feedback is essential.

Without it, the user gropes, loses context, and perhaps starts pressing the keys furiously, until finally resorting to… yes, to mouse clicks, if he can.

Why does this happen? In our case, we found that someone had enthusiastically applied outline: none; to focus states in CSS styles to remove the "ugly" dotted line around links. Aesthetically pleasing, a disaster for the user. Indeed, removing the focus indicator is fatal for keyboard users.

The solution?

Simple: don't turn the indicator off, or replace it with custom styling that fits the design. In the end, we opted for a compromise - instead of the default blue line, we designed a subtle highlight shadow around the active element. The result? The keyboard user can see where they are, the designers don't faint in horror, and the WCAG 2.2 requirement of Focus Visible is met. Win-win.

Trapped in the keyboard trap

After the Focus Visible fiasco, I moved on and soon encountered another tricky thing: the keyboard trap. Imagine a dialogue box (modal) that, when opened, behaves like a California hotel — you can get in, but you can’t get out. That’s precisely what happened to me with our feedback form: I pressed Enter to open it, filled in a few fields, but then… The spreadsheet cycled inside the form, and I couldn’t get to the “Close” button with the keyboard. Esc didn’t work. Focus was stuck. The developer in me panicked: how to get out of this? (In the end, only the mouse helped — ironic, huh?) I realised that if I were a keyboard-reliant user, I had just locked the app and had no chance to continue.

This trap was unintentionally created — we forgot to make sure that the focus from the modal could be returned to the rest of the page. WCAG has this in mind: if you can focus somewhere using the keyboard, there must be a way out. For us, it was enough to make the Close button available in the tab sequence and to allow the Escape key to close the dialogue. After the modification, the focus now correctly jumps from the last field of the dialogue to the Close button. When it is activated (by pressing the Enter or Spacebar key), the focus returns to where the dialogue originally appeared.

No getting stuck, no Alt+F4 emergency. As the Nielsen Norman Group study also points out, it is crucial to give the user the option to close the pop-up window. Otherwise, they will be stuck in it. Now our modal windows work perfectly, and the keyboard doesn’t feel like a prison.

When Tab wanders: a bad sequence

The next lesson didn’t take long to learn. Once we sorted out the focus and traps, I noticed that the element browsing sequence (tab order) in our app didn’t quite make sense. Logically, focus should travel in the order that makes sense visually and logically — typically top to bottom, left to right. But I pressed Tab on the home page, and after the company logo, it jumped straight to the footer, then to the menu, then somewhere in the middle… It’s just a mess. A user who just uses the keyboard would probably think they were crazy or that the page was jumping all over the place.

The bug this time was in the code: we “borrowed” a search component with its tabindex, which overrode the natural order. Some elements were not ideally ordered in the HTML structure, as they appeared visually. Again, the solution was not dramatic — remove the manually set tabindex values (don't use a positive tabindex unless necessary) and adjust the order of the elements in the DOM to match the layout on the page. The result is that now Tab traverses the page in a natural flow: header, menu, main content, sidebar, footer. Simple, clear, usable. By the way, this is precisely what the standards require - the focus should follow a logical and intuitive page hierarchy. If you don't follow this, the keyboard user will get a mental puzzle out of your site instead of a seamless experience.

Are you ready test keyboard only navigation?

How does a “normal day” go without a mouse

This whole experience taught me one important thing: the best way to spot accessibility bugs is to try it out for yourself. Since then, I’ve regularly practised “mouse in drawer, hands on keyboard” testing. How to do it? Here’s my tried-and-true mini-procedure:

• Unplug the mouse (or at least make a firm decision not to touch it). Tab, tab, tab… Scroll through all the controls on the page one by one using the Tab key. Watch to see if you can identify where you are (in focus).
• Shift+Tab to move backwards to try and reverse direction and not create a one-way trap.
• Press Enter or Spacebar to activate buttons and shortcuts, and use the arrow keys to expand menus or scroll through them if needed. Escape to close dialogues or menus. If Esc does nothing and you are trapped, you have a problem.
• End of page? Once you reach the last element, the focus should either cycle back to the beginning (if that makes sense) or stop. Most importantly, it shouldn’t get lost somewhere in limbo.

Such testing takes a few minutes, but it reveals many flaws that automated tests or visual mouse inspections may miss. I put this on my checklist before every new feature release. Fixing these bugs continuously during development is much easier than chasing them back just before the deadline (or worse, after user complaints). Plus, by doing so, we strengthen the overall quality of the code: we think about proper HTML semantic markup, about component manageability, and we hack things less hastily.

From ethics to duty

You might be thinking: okay, a few extra users will be happy, but is it worth the effort?

The answer is: yes. Not just for the sake of those users (although that should be enough — it’s the right thing to do), but also because accessibility is fast becoming a standard that may soon be required by law. For example, public institutions in the EU are already required to have WCAG 2.1 AA-compliant websites. An even wider rollout is in the pipeline: by June 28, 2025, every company doing business in the EU will be required to comply with the European Accessibility Act (EAA). In other words, compliance with accessibility rules (typically WCAG 2.2 Level AA) may soon determine whether your product can go to market, whether it passes public procurement, or whether your business is at risk of legal issues. Today, it may be a competitive advantage and an ethical issue; tomorrow, it may be a hard compliance requirement.

Bottom line

That evening, with a keyboard instead of a mouse was an epiphany for me. It helped me uncover hidden barriers in our application and taught me that accessibility is not an abstract concept from manuals, but a real product quality that affects people every day. We fixed a few minor bugs — added a frame here, adjusted the order there, fixed the closing dialogue — and suddenly our site became more user-friendly. What’s more, these adjustments have not harmed regular users; on the contrary, they have often made it easier for them to use as well (for example, anyone who likes to use the keyboard from a convenient position can now see where they are clearly).

Stylistically speaking, maybe it’s not as “sexy” a job as the new AI-powered features. But the feeling that your product can be fully used by people who would have previously hit a wall is priceless. As a bonus, you have a head start on future regulations and the peace of mind that you’re not discriminating against any user group. The next time you’re evaluating the quality of a web application, try forgetting the mouse for a moment. You might be surprised at what a simple Tabulator will reveal — and how much sense it makes to incorporate this lesson into development permanently.