Skip to content
duxt

Keyboard shortcuts

The four keys the theme binds, where each one applies, and where the reader is told about it.

The theme binds four keys. This page is what they are, when they are listening, and where a reader who has never read this page finds out about them — because a shortcut nobody can discover is a shortcut nobody has.

The bindings

KeysDoesListening while
⌘K · CtrlKOpens search, and closes it againAnywhere on the page, a focused link or button included
?Opens the shortcut sheetThe page's own content holds focus
[The previous page of this sectionThe page's own content holds focus
]The next page of this sectionThe page's own content holds focus

The modifier follows the reader's keyboard, not the author's: ⌘ on an Apple one, Ctrl everywhere else. It is resolved once the browser is there to answer, so a prerendered page ships the safer Ctrl and swaps on arrival.

[ and ] stay inside the section being read. The last page of one section offers no next page into another — crossing a section is what the section row is for, and a key called "next page" that leaves the subject is not the same key.

Where the reader is told

Four places, and all four draw from the same definition, so none of them can come to advertise a key the layer has stopped binding:

  • The search button carries its own chord — ⌘K or Ctrl+K — in the cap on its right.
  • The previous and next links at the foot of a page carry [ and ]. These were the keys nothing mentioned: a reader had to open the sheet to learn that the two links they were already looking at had keys.
  • The keyboard button beside the search opens the sheet with a pointer, on every page from the lg breakpoint up; below it the header hides the button, since a touch screen has no keys to list. It is the answer to the circular part of the problem — ? opens the list of keys, and you have to know that to press it.
  • The sheet itself lists every live binding with its keys, on ? or on that button.

When a key stands down

A global single-character shortcut fires under a reader who never opted into it, so the unmodified keys are guarded rather than merely bound. Nothing fires:

  • once something nearer the key has already handled it;
  • while the reader is typing — an input, a textarea, a select, a contenteditable region;
  • anywhere inside a dialog, menu, listbox, combobox, grid or tree, which answer keystrokes themselves.

The unmodified keys stand down once further: they fire only while the page's own content holds focus, never while a link, button or tab does. ⌘/Ctrl+K is the exception, because no control wants that chord.

A page focus target with tabindex="-1" counts as content, deliberately — that is where focus parks after a navigation, and a reader who has just landed on a page is exactly who [ and ] are for.

Turning the bare keys off

shortcuts.singleCharacter: false unbinds ?, [ and ] and leaves ⌘/Ctrl+K. Switch access, voice control and dictation all emit bare characters as a matter of course, and a page that navigates away under one of them shows no cause; no input method produces the modified chord by accident.

The policy is a boolean rather than a binding table, and that is deliberate: see shortcuts in the configuration reference.

Overriding any of it

The list, the guards and the drawing are one module — useDuxtShortcuts(). The two components around it are DuxtShortcuts, the sheet, and DuxtShortcutsTrigger, the button that opens it. Both are yours to replace the ordinary way; see Override the theme.

Was this page helpful?