Context-menu functions cannot exist only on the right-click path

What it is

Context-menu alternative access requires that functions in a right-click menu are reachable by more than right click alone. Touch, keyboard, switch access, pen input, and some assistive technologies lack right click or make precise secondary clicking hard. Critical commands need an equivalent visible, keyboard, or other-input route.

Why it happens

Right click fuses object targeting and command disclosure into one pointer action, but other channels may only be able to focus or select an object first, then invoke a menu or command separately. Binding a function to right click alone leaves the command with no executable event route for everyone. Application menus, toolbars, shortcuts, command palettes, and focus-triggered menus can all supply an equivalent.

The root cause is that right click is fundamentally a device-specific event, not an intent-specific one: a mouse's secondary button, a trackpad's two-finger tap, a keyboard's Menu key (or Shift+F10), and a touchscreen's long press each fire a different operating-system-level event. If an application listens for only one of them — usually the mouse's right button — it has welded the feature to that device. Conversely, if "open the context menu" is implemented as a single device-independent command that multiple inputs each map onto, the alternative routes need no extra development — they are simply additional entry points into the same logic, not a parallel accessibility implementation bolted on afterward.

Where it stops holding

Not every rare shortcut needs a permanent, duplicated on-screen presence, but it must be discoverable and completable without right click. Long press often opens a touch context menu, but it competes with selection and scrolling (a long press can also start a drag candidate or text selection), so it cannot be the sole alternative. Keyboard menu keys and assistive gestures vary by platform and should follow local convention: Windows keyboards have a Menu key equivalent to Shift+F10, while macOS has no dedicated menu key and typically relies on VoiceOver's rotor or a trackpad two-finger tap instead — a cross-platform app cannot assume any single key combination is universally available.

Applying it

• Give each right-click command a searchable equivalent that acts on the same current target; implement "open the context menu" as a device-independent command rather than writing separate logic per input.
• Support context actions after keyboard focus (Menu key / Shift+F10), and provide a clear More-actions entry point on touch (such as a trailing three-dot button in a list row) instead of requiring people to discover long press on their own.
• How to check: complete every key command with no mouse, no long press, and alternate input, and compare the outcome against the right-click path; specifically check whether commands still fire reliably when long press competes with scrolling or dragging.

Related

• Same group: C1.10.1 Context-menu content changes with the target object · C1.10.2 As menu items grow, search cost exceeds menu benefit
• Nearby: C1.06 Hover states and their absence on touchscreens · J1 Motor and interaction accessibility
• Search terms: context menu accessibility · keyboard menu key · device-independent command