Hacks: Spend One Saturday Using Your Own Product Keyboard-Only

Unplug your mouse. Put it in a drawer. Close the drawer.

That is the hack. The rest of this article is the detail around it, but the hack is: unplug your mouse, put it in a drawer, and use your own product for one Saturday. You will find more accessibility bugs before lunch than you have filed in the last year, and you will find them in the parts of the product you were personally responsible for, which is the part that hurts and also the part that matters.

I am not going to oversell this. It is not a complete audit. It does not replace screen-reader testing, real-user testing, or automated scans. But I have watched designers and developers do this exact exercise for one afternoon and walk away with a more visceral understanding of their product's accessibility debt than a year of tickets gave them. The reason is simple: when you cannot reach for the mouse, every small friction gets amplified. The modal that didn't trap focus becomes a thing you have to close with Alt+F4. The custom dropdown that doesn't respond to arrow keys becomes a dead end. The focus ring you thought looked "clean" becomes invisible and you get lost on your own page.

Why a Saturday specifically

Saturday, because it has to be yours. You cannot do this on company time, or you will cheat — you will pick up the mouse the first time something frustrates you, because you are busy, because the build is failing, because the meeting is at noon. The exercise only works if you are committed to not cheating, and the only way to guarantee you will not cheat is to do it on a day with no external pressure, on your own time, with coffee.

It does not have to be Saturday. It does have to be a block of four hours where nothing else is allowed to interrupt you. Pick the block. Protect it.

The setup

You need three things:

1. Your product, logged in as a normal user, in whatever browser you ship to most users. Not a dev environment. Not staging with fake data. Production. Real data. The actual experience a user has.
2. A physical keyboard you like. You will be on it for hours. If your daily keyboard hurts your wrists, borrow a better one for the day. This is not optional; the thing you are testing is the experience of using a keyboard for a long time, and a bad keyboard will make the test about the keyboard instead of the product.
3. A notes document, open in a second window, reachable by Alt+Tab (or Cmd+Tab). Not a notebook. You will not stop to write things down on paper; it breaks flow. Keep it digital and keep it reachable.

No mouse. No trackpad, either. On a laptop, tape over the trackpad. I am serious. The muscle memory of reaching down to "just this once" scroll with two fingers will defeat you every time if the trackpad is reachable.

The flows to run

You cannot test the whole product in one Saturday. Pick three flows, in this order:

Flow one: signup. Every product has one, and every product's signup has at least three bugs that the team would never have noticed if they hadn't tried to complete it with a keyboard. You will hit them in the first ten minutes. Run the signup, end to end, including email verification. Write down every friction.

Flow two: the main thing your product does. For a task app, create a task, edit it, complete it, delete it. For an ecommerce store, browse, add to cart, check out. For a social product, post something, reply to something, delete something. Whatever your core loop is, run it twice. The first run is discovery. The second run is to see which of the frictions stuck.

Flow three: settings and account management. This is where the bodies are buried. Change your email. Change your password. Update your profile picture (you will probably fail at this one). Update your notification preferences. Delete your account (on a throwaway test account — do not actually delete your production data for this exercise). The settings pages are almost always the most accessibility-broken parts of any product, because they are the lowest-priority pages to polish, and nobody tests them until they have to.

Three flows. Four hours. You will not finish all three. That is fine. Whatever you get through is the pile.

What to write down

You will be tempted to write down "keyboard broken on signup." Don't. Write down the exact moment, the exact key you pressed, and the exact thing that happened. Specifically:

• The step. "Email field on signup page."
• The expected behavior. "Tab should move to password field."
• The actual behavior. "Tab moved to the footer skip link, then the site logo, then the password field."
• The severity in your gut. "Confusing but usable" or "I would have quit if I weren't paid to test this."

The specificity matters because your Saturday notes are going to be your Monday morning tickets, and the notes that make it into tickets are the ones specific enough to fix. "Signup has keyboard issues" will sit in the backlog until the end of time. "Tab order on /signup goes email → footer skip link → logo → password field; should be email → password field directly" is a ticket an engineer can close in fifteen minutes.

The AI assist

Here is where the hack gets interesting. You are going to do the Saturday by hand — that is the whole point, you need the visceral experience — but when you are done, you are going to hand your notes to an AI and let it do the part you are worst at.

The thing you are worst at, after four hours of frustration, is turning your notes into actionable tickets. You are tired, you are slightly angry at your own product, and you want to stop. The AI is not tired. Hand it the notes.

🔍soul-the-accessibility-auditor is the soul I'd open for this. Paste your notes document. Ask it to do three things:

1. Group the notes by root cause. Half of the frictions you wrote down are probably the same underlying bug in different places. The custom dropdown that doesn't respond to arrow keys appears on six pages, but it's one component. The auditor will see the pattern faster than you will on a Saturday night.
2. Sort by severity. Your gut-level severities will be all over the place. The auditor can normalize them against WCAG criteria and actual user impact. You still get the final call, but you will not miss a P0 because you wrote it down when you were tired.
3. Draft tickets. One per root cause, with the specific steps to reproduce, the specific fix, and the WCAG criterion it maps to. These are not final tickets. They are drafts. But the drafts will be better than the tickets you would have written at 10 p.m.

⌨️skill-keyboard-only-walkthrough is the more structured version of this — a full protocol for running a ⌨️keyboard-only walkthrough on a specific page and producing a report. If you want to do this exercise as part of a formal audit instead of as a Saturday hack, start there. The Saturday version is the one I am recommending because it is the one people actually do.

One more prompt worth running: 📝prompt-form-label-audit on the signup form specifically. Most of the keyboard frictions on signup are also label frictions — the field that didn't take focus properly, the error that didn't announce, the required-field marker that was visual-only. The prompt catches all of these in a single pass and turns them into a second tight list of tickets that overlap with your Saturday notes in ways you'll find useful.

The things you'll find that aren't on any checklist

This is the part that makes the Saturday exercise different from any automated audit: you will find things that no tool would have flagged.

• The moment you lose the focus ring. It was there on the previous page. On this page, the background is almost the same color as the focus ring, and you can't tell where you are anymore, and you tab five times hoping to land somewhere you recognize. This is a contrast bug that would pass most automated checks because the ring exists; it just doesn't exist against this specific background.
• The modal that opens below the fold. A modal triggered by a button at the top of the page opens visually in the center of the viewport — which is fine — but the keyboard focus moves to the first element in the modal, which is below the current scroll position, and the page does not auto-scroll. You press Enter. Nothing visible happens. Because you cannot see the modal, you think nothing happened. You press the button again. Two modals now exist, stacked, and you cannot tell.
• The search field that Enter doesn't submit. The designer intended for the search to submit on button click. The button is visible. The keyboard user expects Enter to work in a search field because Enter always works in a search field. It does not. The user types the query, presses Enter, nothing happens, gives up.
• The "drag to reorder" interaction with no keyboard alternative. The list is reorderable by dragging. There is no keyboard alternative. The entire feature is unusable by keyboard. You did not know this until Saturday.

Each of these is the kind of bug that shows up only when you use the product the way your users use it, and none of them are rare. I am confident that if you run this exercise, you will find at least three of them, and at least one of them will be in a part of the product you personally worked on.

That last part is the lesson. The exercise is not about finding bugs, exactly. It is about calibrating your internal sense of what "accessible enough" means against the actual experience of a keyboard-only user. Once you have felt the frustration of losing the focus ring on your own checkout page, you will never again ship a page without checking the focus ring against every background color you use. The calibration is permanent.

Do this Saturday

• Saturday morning. Coffee. Unplug the mouse. Put it in the drawer. Tape the trackpad.
• Four hours. Three flows: signup, core loop, settings.
• Notes document open in the background, reachable by Alt+Tab.
• At the end of the four hours, plug the mouse back in, open 🔍soul-the-accessibility-auditor, paste your notes, and let it turn them into tickets.
• Monday morning, file the top five. Not all of them. Five. The rest can come next Saturday.

The hack is the unplugged mouse. The rest of the work is just following through.

If this feels small — and it will, because "unplug your mouse" sounds like a gimmick — remember that the reason it works is not that it is clever. It is that nobody actually does it. The gap between the teams that ship accessible keyboard experiences and the teams that don't is not a gap in tooling or knowledge. It is a gap in whether, at any point, anyone on the team spent four hours using the product the way a keyboard user uses it.

Be the person who spent the Saturday. You will be the person on the team who catches the focus ring bug every time, for the rest of your career, in every product you work on, and you will be catching it in ten seconds instead of never, because you know what it feels like to lose it.

Part of the a-gnt "Hacks" series.