# Adding a keyboard shortcut to open feedback

> Add a keyboard shortcut with a modifier combination that browsers and operating systems do not use, match the key by its code, skip keystrokes typed into fields, and call EscutaProduto.open with a kind. Show the shortcut in your interface so people can find it.

Source: https://escutaproduto.com/resources/keyboard-shortcut-open-feedback
Last updated: 2026-10-11

## Which keys are safe to use for a feedback shortcut?

A safe shortcut uses a combination the browser, the operating system and your own app do not already use. Single letters are the riskiest choice, because people type those letters into search boxes and comment fields all day. Command or Control with a letter is also risky, since most of those combinations already open something in the browser, such as find, bookmarks or a new tab.

A modifier combination that is rarely used works best, such as Alt plus Shift plus a letter. Test the choice on Windows, Linux and macOS, because a combination that works on one system can produce a special character on another. On a Mac, the Option key changes the character that the letter key produces, so match the key by its physical position instead of its character.

## How do you open the widget from a keyboard handler?

The widget exposes `EscutaProduto.open({ kind })`, where the kind preselects the type: `bug`, `idea`, `praise` or `other`. Call it from a document-level `keydown` listener. Check that the API exists before you call it, because the script may still be loading when the first key is pressed:

```js
document.addEventListener("keydown", function (event) {
  if (event.repeat || event.defaultPrevented) return;
  if (!(event.altKey && event.shiftKey && event.code === "KeyF")) return;

  const target = event.target;
  if (target instanceof HTMLElement && isTypingTarget(target)) return;

  const api = window.EscutaProduto;
  if (!api || typeof api.open !== "function") return;

  event.preventDefault();
  api.open({ kind: "bug" });
});

function isTypingTarget(element) {
  return element.isContentEditable || ["INPUT", "TEXTAREA", "SELECT"].includes(element.tagName);
}
```

The `event.code` value stays the same across keyboard layouts and when Option changes the character, so `KeyF` is more reliable than `event.key` for a shortcut with modifiers. The `repeat` check stops the panel from opening again while a key is held down.

## How do you ignore keystrokes typed into fields?

Typing must always win. A visitor who writes an email address or a comment should never trigger the shortcut by accident, and a shortcut that steals a key from a text field is a serious accessibility problem. The handler above returns early for inputs, text areas, select menus and any element that is editable. Check for those elements on every keystroke, not once at page load, because fields can appear as the page changes.

Also ignore the shortcut when a modal dialog from your own app is open, unless you intend the shortcut to work there. Your own dialogs usually handle Escape and Tab in their own ways, and an extra listener can make them behave in surprising ways.

## What about focus when the panel closes?

The widget closes on Escape, and focus returns to the trigger when you open the panel from a button. A shortcut has no trigger, so focus may not return to a sensible place. Test this directly: press the shortcut from a paragraph, send nothing, press Escape, and see where the focus lands. If it lands at the top of the page, move focus to a visible control of your own before you call `open`, so the return point is a known element.

For people who use a screen reader, announce the change in your own interface if the page content shifts. The widget's focus rules are described in [how to make a feedback widget accessible](/resources/accessible-feedback-widget).

## Should the shortcut replace the visible button?

No. A shortcut helps people who already know the keyboard, but many visitors will never learn it, and some will use assistive technology that does not expose your key bindings. Keep the visible button in the same place, and treat the shortcut as an addition. The two paths should open the same panel with the same type options, so a visitor who discovers either one gets the same result.

If your site already uses single-key shortcuts for its own features, such as a search key or arrow navigation in a gallery, do not add another single key. Choose a combination that your own code does not use, and list all of your shortcuts in one place so they stay consistent.

## How do you show people the shortcut so they find it?

A shortcut nobody knows about only helps the person who wrote it. Show it in two or three places:

1. Add `aria-keyshortcuts` to the button that opens the widget, so assistive technology can announce the shortcut.
2. Print the combination in a help menu, a footer link or a keyboard shortcuts page, with the Mac version beside the Windows version.
3. Mention it once in your onboarding, not on every page.

```html
<button type="button" data-escuta-open="idea" aria-keyshortcuts="Alt+Shift+F">Suggest an idea</button>
```

Use the attribute on a real button that opens the same widget. A visible hint, such as "Alt+Shift+F, or Option+Shift+F on Mac", helps sighted users, and the attribute helps screen reader users.

## Which conflicts should you test before shipping?

Test the shortcut on each browser and operating system your visitors use, then check the list below:

| Check | Expected result |
| --- | --- |
| Type in a search box, then press the shortcut | Text stays, the panel does not open |
| Press the shortcut with an email field focused | Nothing happens |
| Hold the shortcut down | The panel opens once |
| Press the shortcut before the script loads | Nothing breaks, and the panel opens once the script is ready |
| Press Escape after opening | The panel closes and focus lands on a visible element |
| Press the shortcut on a Mac with Option | The panel opens with the same key position |

## Wiring the shortcut into Escuta Produto

Add the widget script as usual, then add the keydown handler after it. Keep the default floating button unless you have a reason to remove it, because the shortcut is an addition for people who prefer the keyboard, not a replacement for the visible control. Setup details for the script and the attributes are in the [widget docs](/docs/widget). For the copy of the buttons people click, see [what a feedback button should say](/resources/feedback-button-copy).

## Frequently asked questions

### Which keyboard shortcut should open a feedback form?

Pick a rarely used combination with Alt and Shift plus a letter, which browsers rarely reserve. Avoid single letters, because people type them in fields, and avoid Command or Control combinations that browsers already use for common actions.

### How do I stop a feedback shortcut from firing while someone types?

Check the event target on each keydown. Return early when the target is an input, a text area, a select menu or an editable element. Do this on every keystroke, because fields can appear as the page changes.

### How do I open the Escuta Produto widget from a keyboard shortcut?

Call EscutaProduto.open with a kind such as bug, idea, praise or other. Check that the function exists first, because the script may still be loading, and call preventDefault so the browser does not also act on the key.