The web was built for two hands. One on the keyboard, one on the mouse. Nearly every browser interaction — copying text, switching tabs, searching a page, navigating history — assumes you can comfortably reach both input devices at the same time. For millions of people, that assumption doesn't hold.
Roughly 1 in 7 adults worldwide lives with some form of motor disability. That includes cerebral palsy, muscular dystrophy, multiple sclerosis, stroke-related paralysis, repetitive strain injury (RSI), arthritis, amputations, and a long list of temporary conditions like broken bones, post-surgical recovery, and tendonitis flare-ups. For all these people, the two-handed model isn't a minor inconvenience — it's a barrier that makes basic browsing tasks harder than they need to be.
This article makes the case that gesture-based browsing — specifically, radial menus activated by mouse movement — is one of the most practical tools for closing this gap. Not as a replacement for existing assistive technologies, but as a complement that addresses a specific, underserved need: one-handed, mouse-only interaction with a standard browser.
Where WCAG and Browser Accessibility Fall Short
The Web Content Accessibility Guidelines (WCAG) are the global standard for web accessibility. They cover a wide range of needs: screen reader compatibility, color contrast, text resizing, captions, alternative text for images, and keyboard navigability. WCAG has driven enormous improvements in how websites serve users with visual, auditory, and cognitive disabilities.
Motor accessibility, however, gets less attention. WCAG 2.1 added some provisions — Success Criterion 2.5.1 requires that all pointer-based functionality be operable with single-pointer input, and 2.5.4 limits motion-only activation. These are useful guard rails. But they address what websites should do, not what browsers do. And the browser itself — Chrome, Firefox, Edge — is where the motor accessibility gap is widest.
Chrome has no built-in way to perform common actions using only a mouse. Want to copy text? You need Ctrl+C. Want to close a tab? Ctrl+W. Open a new one? Ctrl+T. Navigate back? Alt+Left Arrow. Every one of these requires the keyboard. Chrome's settings offer no mouse-only alternative, no customization for one-handed use, and no gesture system of any kind.
This means that even if every website on the internet achieves perfect WCAG compliance, a person who can only use a mouse still can't copy a paragraph without reaching for a keyboard or invoking a right-click context menu and aiming at a narrow dropdown item. The gap is in the browser, not the website.
Motor Disabilities and One-Handed Browsing
Motor disabilities that affect browsing typically fall into a few categories:
- Loss of use of one hand — hemiplegia from stroke, amputation, nerve damage, or a temporary injury like a broken wrist. The user can only operate one input device at a time.
- Reduced fine motor control — conditions like Parkinson's disease, essential tremor, or advanced arthritis make precise cursor movements and small target areas difficult. Clicking a 12-pixel-wide menu item is genuinely hard.
- Reduced strength or endurance — muscular dystrophy, MS fatigue, or post-surgical weakness may mean the user can operate a mouse but not sustain keyboard use for extended periods.
- Repetitive strain injury — RSI, carpal tunnel syndrome, and tendonitis often affect the dominant hand's wrist and fingers. Using a keyboard exacerbates the condition; switching to mouse-only interaction can be part of a recovery strategy.
In all these cases, the user's fundamental need is the same: perform standard browsing actions without requiring both hands on separate input devices. That's the problem gesture-based browsing solves.
Existing Assistive Approaches
Several assistive technologies address motor accessibility in different ways. Each has strengths, and each has limitations that leave a gap.
Voice control (Dragon NaturallySpeaking, Windows Voice Access, macOS Voice Control) lets users speak commands and dictate text. It's powerful for text input and system-level commands, but less effective for rapid, repetitive browser actions. Saying "click Copy" is slower than pressing Ctrl+C, and voice control struggles in noisy environments, shared spaces, and situations where speaking aloud isn't feasible — a library, an open office, a late-night browsing session with a sleeping partner nearby.
Switch access uses physical switches (buttons, sip-and-puff devices, head-motion sensors) to navigate the screen. It's essential for people with very limited movement, but it's slow by design — the interface scans through options one at a time, and the user activates a switch when the correct option is highlighted. For someone who can use a mouse but not a keyboard, switch access is far more restrictive than necessary.
On-screen keyboards display a virtual keyboard that can be operated with a mouse. They solve the text-input problem but don't help with keyboard shortcuts. To "press" Ctrl+C on an on-screen keyboard, you need to click the Ctrl key, then click the C key — two precise clicks on small targets, which is exactly the kind of fine-motor task that some users are trying to avoid.
Eye tracking allows cursor control via gaze direction. It's remarkable technology for users with very limited physical movement, but it's expensive, requires calibration, and struggles with the precision needed for small UI targets. It also causes eye fatigue over long sessions.
What's missing is a tool for the large middle ground: people who can move a mouse and click, but can't comfortably use a keyboard. They don't need a full assistive framework. They need a way to trigger browser actions — copy, paste, close tab, open link, navigate back — using only the mouse. That's what a radial menu provides.
Why Radial Menus Work for Motor Accessibility
Radial menus have inherent properties that align well with motor accessibility needs:
Large target areas. Each wedge in a radial menu subtends a wide arc. In Wilee's default 8-wedge layout, each target covers 45 degrees of angle — a massive hit zone compared to a 12-pixel-tall dropdown menu item. You don't need to aim precisely. You need to move roughly in the right direction. This is exactly what Fitts's Law predicts: large, close targets are faster and easier to hit, and radial menus maximize both properties.
No keyboard required. The entire interaction — open menu, select action, confirm — happens with the mouse. Hold the trigger button, move in a direction, release. One hand, one device, one motion. No modifier keys, no key combinations, no switching between input devices.
Adjustable sensitivity. Wilee lets users configure the flick distance threshold — the minimum number of pixels the cursor must travel to register a selection. Users with limited range of motion can reduce this to a few pixels; users with tremor can increase it to filter out involuntary movements. The hold threshold (how long you press before the menu appears) is also adjustable, preventing accidental activations.
Multiple layout options. Not everyone can flick in eight directions comfortably. Wilee offers a 4-wedge layout (cardinal directions only, with larger targets), an arc layout (semicircle, thumb-friendly for trackpad users), a 3x3 grid (no directional flick required — just click the cell), and a honeycomb layout with six hexagonal tiles. Users choose the layout that matches their physical capabilities.
Scalable menu size. Four size presets — Small, Medium, Large, and X-Large — let users scale the menu to match their comfort zone. X-Large targets are 75% bigger than the default, making them easier to hit for users with reduced motor precision.
Design Decisions That Prioritize Accessibility
Wilee's internal framing is "accessibility tool that happens to be fast," not the reverse. Several design decisions reflect this priority:
High-contrast theme. A dedicated high-contrast theme (black on white, white on black) ensures the menu is visible to users with low vision. This isn't decorative — it's a distinct rendering mode with maximum foreground-background separation, designed to meet WCAG AAA contrast ratios.
Reduced motion mode. Animations (cursor trails, snap-pulse effects) can be disabled with a single toggle. Wilee also respects the operating system's reduced-motion preference automatically — if your OS is set to reduce animations, Wilee's menu opens instantly with no animation, without requiring any Wilee-specific configuration.
Slot numbers. An optional overlay displays position numbers (1, 2, 3...) on each wedge, so users can identify slots by position rather than relying on color or icon recognition alone. Combined with keyboard navigation (arrow keys cycle through wedges, number keys select directly), this provides an alternative input path for users who can use a keyboard but find mouse precision difficult.
Full keyboard navigation. For users who have the opposite problem — they can use a keyboard but not a mouse — Wilee's menu can be opened via Ctrl+Shift+Space (customizable) and navigated entirely with arrow keys, Tab, and Enter. This ensures the tool doesn't create an accessibility gap in the other direction.
Click-to-pick mode. The default interaction is flick-to-pick: hold the trigger, drag in a direction, release. But some users find the simultaneous hold-and-drag motion difficult. Click-to-pick mode separates the steps: press the trigger to open the menu, release, then left-click the desired wedge. Two distinct actions instead of one compound gesture, which can be easier for users with coordination challenges.
Free Pro for Motor Limitations
Wilee Pro — which includes additional layouts, themes, site rules, and LLM integration — is free for anyone with a motor limitation. The system is honor-based: in Wilee's Accessibility settings, check the box that says "I have a motor limitation and would like free Pro." No documentation required, no verification process, no hoops to jump through. Checking the box is enough.
This decision is deliberate. Documentation requirements create friction, and friction disproportionately affects the people who need the tool most. Requiring a doctor's note to unlock an accessibility feature is asking someone to prove they deserve access — which is the wrong framing entirely. If someone says they have a motor limitation, the right response is to believe them and unlock the features.
The honor system means some people without motor limitations will check the box. That's fine. The cost of a few people getting Pro features for free is negligible compared to the cost of a single person with a genuine motor limitation being blocked by a verification process they can't complete.
Practical Scenarios
To make this concrete, here are scenarios where gesture-based browsing changes the experience:
Post-stroke browsing. A stroke survivor with left-side hemiplegia uses a mouse with their right hand. Without a radial menu, they can browse pages but can't copy text, switch tabs, or navigate history without an on-screen keyboard or voice command. With Wilee, they hold the right mouse button, flick toward Copy or Close Tab or Back, and release. Every common action is one gesture away.
RSI recovery. A software developer with wrist tendonitis needs to reduce keyboard use during recovery. They switch to Wilee for browsing, using the radial menu for all actions they'd normally do with shortcuts. The mouse-only workflow lets their wrist rest while still doing research, reading documentation, and sending text to LLMs for quick answers.
Arthritis and precision loss. A retiree with arthritis in both hands finds Chrome's small context menu items difficult to click accurately. Wilee's X-Large 4-wedge layout gives them four huge directional targets. They don't need to hit a specific pixel — just move roughly up, down, left, or right.
Temporary injury. A college student breaks their left wrist snowboarding. For six weeks, every browsing session that requires Ctrl+anything is awkward and painful. They install Wilee, use it mouse-only for the recovery period, and discover they prefer it even after the cast comes off.
Browsing Should Not Require Two Hands
The assumption that browsing requires two hands is a legacy of 1990s interface design that the industry has been slow to revisit. Voice assistants, touch interfaces, and gesture systems have all challenged this assumption on other platforms. The desktop browser is one of the last holdouts.
Gesture-based browsing with a radial menu doesn't replace screen readers, voice control, or switch access. It fills a specific gap: mouse-only interaction for people who can point and click but can't comfortably use a keyboard. That's a large population, it includes both permanent and temporary conditions, and until recently, there was no browser-level solution for it.
Wilee isn't the only tool working on this, but it's the one built from the ground up with accessibility as a first principle rather than an afterthought. Every layout, every theme, every interaction mode was designed with the question: does this work for someone using one hand?